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Software  certification  is  a  promising  approach  to  producing  programs  which  are  virtually  free  of  bugs. 
It  requires  the  construction  of  a  formal  proof  which  establishes  that  the  code  in  question  will  behave 
according  to  its  specification  -  a  higher-level  description  of  its  functionality.  The  construction  of  such 
formal  proofs  is  carried  out  in  tools  called  proof  assistants.  Advances  in  the  current  state-of-the-art  proof 
assistants  have  enabled  the  certification  of  a  number  of  complex  and  realistic  systems  software. 

Despite  such  success  stories,  large-scale  proof  development  is  an  arcane  art  that  requires  significant 
manual  effort  and  is  extremely  time-consuming.  The  widely  accepted  best  practice  for  limiting  this  ef¬ 
fort  is  to  develop  domain-specific  automation  procedures  to  handle  all  but  the  most  essential  steps  of 
proofs.  Yet  this  practice  is  rarely  followed  or  needs  comparable  development  effort  as  well.  This  is  due 
to  a  profound  architectural  shortcoming  of  existing  proof  assistants:  developing  automation  procedures 
is  currently  overly  complicated  and  error-prone.  It  involves  the  use  of  an  amalgam  of  extension  languages, 
each  with  a  different  programming  model  and  a  set  of  limitations,  and  with  significant  interfacing  prob¬ 
lems  between  them. 

This  thesis  posits  that  this  situation  can  be  significantly  improved  by  designing  a  proof  assistant  with 
extensibility  as  the  central  focus.  Towards  that  effect,  I  have  designed  a  novel  programming  language  called 
VeriML,  which  combines  the  benefits  of  the  different  extension  languages  used  in  current  proof  assistants 
while  eschewing  their  limitations.  The  key  insight  of  the  VeriML  design  is  to  combine  a  rich  program¬ 
ming  model  with  a  rich  type  system,  which  retains  at  the  level  of  types  information  about  the  proofs 
manipulated  inside  automation  procedures.  The  effort  required  for  writing  new  automation  procedures 
is  significantly  reduced  by  leveraging  this  typing  information  accordingly. 

I  show  that  generalizations  of  the  traditional  features  of  proof  assistants  are  a  direct  consequence  of  the 
VeriML  design.  Therefore  the  language  itself  can  be  seen  as  the  proof  assistant  in  its  entirety  and  also  as 
the  single  language  the  user  has  to  master.  Also,  I  show  how  traditional  automation  mechanisms  offered 
by  current  proof  assistants  can  be  programmed  directly  within  the  same  language;  users  are  thus  free  to 
extend  them  with  domain-specific  sophistication  of  arbitrary  complexity. 

In  this  dissertation  I  present  all  aspects  of  the  VeriML  language:  the  formal  definition  of  the  language; 
an  extensive  study  of  its  metatheoretic  properties;  the  details  of  a  complete  prototype  implementation; 
and  a  number  of  examples  implemented  and  tested  in  the  language. 
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Chapter  1 

Introduction 


Computer  software  is  ubiquitous  in  our  society.  The  repercussions  of  software  errors  are  becoming  in¬ 
creasingly  more  severe,  leading  to  huge  financial  losses  every  year  [e.g.  Zhivich  and  Cunningham,  2009] 
and  even  resulting  in  the  loss  of  human  lives  [e.g.  Blair  et  ah,  1992,  Lions  et  ah,  1996].  A  promising  re¬ 
search  direction  towards  more  robust  software  is  the  idea  of  certified  software  [Shao,  2010]:  software  that 
comes  together  with  a  high-level  description  of  its  behavior  -  its  specification.  The  software  itself  is  related 
to  its  specification  through  an  unforgeable  formal  proof  that  includes  all  possible  details,  down  to  some 
basic  mathematical  axioms.  Recent  success  stories  in  this  field  include  the  certified  optimizing  C  compiler 
[Leroy,  2009]  and  the  certified  operating  system  kernel  seL4  [Klein  et  ah,  2009]. 

The  benefit  of  formal  proofs  is  that  they  can  be  mechanically  checked  for  validity  using  a  small  com¬ 
puter  program,  owing  to  the  high  level  of  detail  that  they  include.  Their  drawback  is  that  they  are  hard 
to  write,  even  when  we  utilize  proof  assistants  -  specialized  tools  that  are  designed  to  help  in  formal  proof 
development.  We  argue  that  this  is  due  to  a  profound  architectural  shortcoming  of  current  proof  assis¬ 
tants:  though  extending  a  proof  assistant  with  domain-specific  sophistication  is  of  paramount  importance 
for  large-scale  proof  development  [e.g.  Chlipala  et  ah,  2009,  Morrisett  et  ah,  2012],  developing  such  ex¬ 
tensions  (in  the  form  of  proof  producing  procedures)  is  currently  overly  complex  and  error-prone. 

This  dissertation  is  an  attempt  to  address  this  shortcoming  of  formal  proof  development  in  current 
systems.  Towards  that  end,  I  have  designed  and  developed  a  new  programming  language  called  VeriML, 
which  serves  as  a  novel  proof  assistant.  The  main  benefit  of  VeriML  is  that  it  includes  a  rich  type  system 
which  provides  helpful  information  and  robustness  guarantees  when  developing  new  proof-producing 
procedures  for  specialized  domains.  Furthermore,  users  can  register  such  procedures  to  be  utilized  trans¬ 
parently  by  the  proof  assistant,  so  that  the  development  of  proofs  and  further  procedures  can  be  signifi¬ 
cantly  simplified.  Though  an  increasing  number  of  trivial  details  can  be  omitted  in  this  way  from  proofs 
and  proof  procedures,  the  type  system  ensures  that  this  does  not  eschew  logical  soundness  -  the  resulting 
proofs  are  as  trustworthy  as  formal  proofs  with  full  details.  This  leads  to  a  truly  extensible  proof  assistant 
where  domain-specific  sophistication  can  be  built  up  in  layers. 

1.1  Problem  description 

Formal  proof  development  is  a  complicated  endeavor.  Formal  proofs  need  to  contain  all  possible  details, 
down  to  some  basic  logical  axioms.  Contrast  this  with  the  informal  proofs  of  normal  mathematical 
practice:  one  needs  to  only  point  out  the  essential  steps  of  the  argument  at  hand.  The  person  reading 
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the  proof  needs  to  convince  themselves  that  these  steps  are  sufficient  and  valid,  relying  on  their  intuition 
or  even  manually  reconstructing  some  missing  parts  of  the  proof  (e.g.  when  the  proof  mentions  that 
a  certain  statement  is  trivial,  or  that  ‘other  cases  follow  similarly’).  This  is  only  possible  if  they  are 
sufficiently  familiar  with  the  specific  domain  of  the  proof.  Thus  the  distinguishing  characteristic  is  that 
the  receiver  of  an  informal  proof  is  expected  to  possess  certain  sophistication,  whereas  the  receiver  of 
formal  proof  is  an  absolutely  skeptical  agent  that  only  knows  of  certain  basic  reasoning  principles. 

Proof  assistants  are  environments  that  provide  users  with  mechanisms  for  formal  proof  development, 
which  bring  this  process  closer  to  writing  down  an  informal  proof.  One  such  mechanism  is  tactics :  func¬ 
tions  that  produce  proofs  under  certain  circumstances.  Alluding  to  a  tactic  is  similar  to  suggesting  a 
methodology  in  informal  practice,  such  as  ‘use  induction  on  Tactics  range  from  very  simple,  corre¬ 
sponding  to  basic  reasoning  principles,  to  very  sophisticated,  corresponding  to  automated  proof  discovery 
for  large  classes  of  problems. 

When  working  on  a  large  proof  development,  users  are  faced  with  the  choice  of  either  using  the 
already  existing  tactics  to  write  their  proofs,  or  to  develop  their  own  domain-specific  tactics.  The  latter 
choice  is  often  suggested  as  advantageous  [e.g.  Morrisett  et  ah,  2012],  as  it  leads  to  more  concise  proofs 
that  omit  details,  which  are  also  more  robust  to  changes  in  the  specifications  -  similar  to  informal  proofs 
that  expect  a  certain  level  of  domain  sophistication  on  the  part  of  the  reader.  But  developing  new  tactics 
comes  with  its  own  set  of  problems,  as  tactics  in  current  proof  assistants  are  hard  to  write.  The  reason  is 
that  the  workflow  that  modern  proof  assistants  have  been  designed  to  optimize  is  developing  new  proofs, 
not  developing  new  tactics.  For  example,  when  a  partial  proof  is  given,  the  proof  assistant  informs  the 
user  about  what  remains  to  be  proved;  thus  proofs  are  usually  developed  in  an  interactive  dialog  with 
the  proof  assistant.  Similar  support  is  not  available  for  tactics  and  would  be  impossible  to  support  using 
current  tactic  development  languages.  Tactics  do  not  specify  under  which  circumstances  they  are  supposed 
to  work,  the  type  of  arguments  they  expect,  what  proofs  they  are  supposed  to  produce  and  whether  the 
proofs  they  produce  are  actually  valid.  Formally,  we  say  that  tactic  programming  is  untyped.  This  hurts 
composability  of  tactics  and  also  allows  a  large  potential  for  bugs  that  occur  only  on  particular  invocations 
of  tactics.  This  lack  of  information  is  also  what  makes  interactive  development  of  tactics  impossible. 

Other  than  tactics,  proof  assistants  also  provide  mechanisms  that  are  used  implicitly  and  ubiquitously 
throughout  the  proof.  These  aim  to  handle  trivial  details  that  are  purely  artifacts  of  the  high  level  of  rigor 
needed  in  a  formal  proof,  but  would  not  be  mentioned  in  an  informal  proof.  Examples  are  the  conversion 
rule,  which  automates  purely  computational  arguments  (e.g.  determining  that  5!  =  120),  and  unification 
algorithms,  which  aim  to  infer  details  of  the  terms  used  in  a  proof  that  can  be  easily  determined  from  the 
context  (e.g.  determining  that  the  generic  addition  symbol  +  refers  to  natural  number  addition  when  used 
as  5  +  x).  The  mechanism  of  the  conversion  rule  is  even  integrated  with  the  base  proof  checker,  in  order 
to  keep  formal  proofs  feasible  in  terms  of  size.  We  refer  to  these  mechanisms  as  small-scale  automation  in 
order  to  differentiate  them  from  large-scale  automation  which  is  offered  by  explicit  reference  to  specific 
automation  tactics  and  development  of  further  ones,  following  Asperti  and  Sacerdoti  Coen  [2010], 

Small-scale  automation  mechanisms  usually  provide  their  own  ways  for  adding  domain-specific  exten¬ 
sions  to  them;  this  allows  users  to  provide  transparent  automation  for  the  trivial  details  of  the  domain  at 
hand.  For  example,  unification  mechanisms  can  be  extended  through  first-order  lemmas;  and  the  conver¬ 
sion  rule  can  support  the  development  of  automation  procedures  that  are  correct  by  construction.  Still, 
the  programming  model  that  is  supported  for  these  extensions  is  inherrently  quite  limited.  In  the  case  of 
the  conversion  rule  this  is  because  of  its  tight  coupling  with  the  core  of  the  proof  assistant;  in  the  case  of 
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unification,  this  because  of  the  very  way  the  automation  mechanism  work.  On  the  other  hand,  the  main 
cost  in  developing  such  extensions  is  in  proving  associated  lemmas;  therefore  it  significantly  benefits  from 
the  main  workflow  of  current  proof  assistants  for  writing  proofs. 

Contrasting  this  distinction  between  small-scale  and  large-scale  automation  with  the  practice  of  infor¬ 
mal  proof  reveals  a  key  insight:  the  distinction  between  what  constitutes  a  trivial  detail  that  is  best  left 
implicit  and  what  constitutes  an  essential  detail  of  a  proof  is  very  thin;  and  it  is  arbitrary  at  best.  Further¬ 
more,  as  we  progress  towards  more  complex  proofs  in  a  certain  domain,  or  from  one  domain  A  to  a  more 
complicated  one  B,  which  presupposes  domain  A  (e.g.  algebra  and  calculus),  it  is  crucial  to  omit  more  de¬ 
tails.  Therefore,  the  fact  that  small-scale  automation  and  large-scale  automation  are  offered  through  very 
different  means  is  a  liability  in  as  far  as  it  precludes  moving  automation  from  one  side  to  the  other.  Users 
can  develop  the  exact  automation  algorithms  they  have  in  mind  as  a  large-scale  automation  tactic;  but 
there  is  significant  re-engineering  required  if  they  want  this  to  become  part  of  the  ‘background  reasoning’ 
offered  by  the  small-scale  automation  mechanisms.  They  will  have  to  completely  rewrite  those  algorithms 
and  even  change  the  data  structures  they  use,  in  order  to  match  the  limitations  of  the  programming  model 
for  small-scale  automation.  In  cases  where  such  limitations  would  make  the  algorithms  suboptimal,  the 
only  alternative  is  to  extend  the  very  implementation  of  the  small-scale  automation  mechanisms  in  the 
internals  of  the  proof  assistant.  While  this  has  been  attempted  in  the  past,  it  is  obviously  associated  with 
a  large  development  cost  and  raises  the  question  whether  the  overall  system  is  still  logically  sound. 

Overall,  users  are  faced  with  a  choice  between  multiple  mechanisms  when  trying  to  develop  automa¬ 
tion  for  a  new  domain.  Each  mechanism  has  its  own  programming  model  and  a  set  of  benefits,  issues 
and  limitations.  In  many  cases,  users  have  to  be  proficient  in  multiple  of  these  mechanisms  in  order  to 
achieve  the  desired  result  in  terms  of  verbosity  in  the  resulting  proof,  development  cost,  robustness  and  ef¬ 
ficiency.  The  fact  that  significant  issues  exist  in  interfacing  between  the  various  mechanisms  and  languages 
involved,  further  limits  the  extensibility  and  reusability  of  the  automation  that  users  develop. 

In  this  dissertation,  we  propose  a  novel  architecture  for  proof  assistants,  guided  from  the  following 
insights.  First,  development  of  proof-producing  procedures  such  as  tactics  should  be  a  central  focal  point 
for  proof  assistants,  just  as  development  of  proofs  is  of  central  importance  in  current  proof  assistants.  Sec¬ 
ond,  the  distinction  between  large-scale  automation  and  small-scale  automation  should  be  de-emphasized 
in  light  of  their  similarities:  the  involved  mechanisms  are  in  essence  proof-producing  procedures,  which 
work  under  certain  circumstances  and  leverage  different  algorithms.  Third,  that  writing  such  proof- 
producing  procedures  in  a  single  general-purpose  programming  model  coupled  with  a  rich  type  system, 
directly  offers  the  benefits  of  the  traditional  proof  assistant  architecture  and  generalizes  them. 

Based  on  these  insights,  we  present  a  novel  language-based  architecture  for  proof  assistants.  We  propose 
a  new  programming  language,  called  VeriML,  which  focuses  on  the  development  of  typed  proof-producing 
procedures.  Proofs,  as  well  as  other  logic-related  terms  such  as  propositions,  are  explicitly  represented  and 
manipulated  in  the  language;  their  types  precisely  capture  the  relationships  between  such  terms  (e.g.  a 
proof  which  proves  a  specific  proposition).  We  show  how  this  language  enables  us  to  support  the  tradi¬ 
tional  workflows  of  developing  proofs  and  tactics  in  current  proof  assistants,  utilizing  the  information 
present  in  the  type  system  to  recover  and  extend  the  benefits  associated  with  these  workflows.  We  also 
show  that  small-scale  automation  mechanisms  can  be  implemented  within  the  language,  rather  than  be 
hardcoded  within  its  internal  implementation.  We  demonstrate  this  fact  through  an  implementation  of 
the  conversion  rule  within  the  language;  we  show  how  it  can  be  made  to  behave  identically  to  a  hardcoded 
conversion  rule.  In  this  way  we  solve  the  long-standing  problem  of  enabling  arbitrary  user  extensions  to 
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conversion  while  maintaining  logical  soundness,  by  leveraging  the  rich  type  system  of  the  language.  Last, 
we  show  that  once  domain-specific  automation  is  developed  it  can  transparently  benefit  the  development 
of  not  only  proofs,  but  further  tactics  and  automation  procedures  as  well.  Overall,  this  results  in  a  style  of 
formal  proof  that  comes  one  step  closer  to  informal  proof,  by  increasing  the  potential  for  omitting  details, 
while  maintaining  the  same  guarantees  with  respect  to  logical  soundness. 

1.2  Thesis  statement 

The  thesis  statement  that  this  dissertation  establishes  follows. 

A  type-safe  programming  language  combining  typed  manipulation  of  logical  terms  with  a 
general-purpose  side-effectful  programming  model  is  theoretically  possible,  practically  imple- 
mentable,  viable  as  an  alternative  architecture  for  a  proof  assistant  and  offers  improvements 
over  the  current  proof  assistant  architectures. 

By  ‘logical  terms’  we  refer  to  the  terms  of  a  specific  higher-order  logic,  such  as  propositions  and  proofs. 
The  logic  that  we  use  is  called  dHOL  and  is  specified  as  a  type  system  in  Chapter  3.  By  ‘manipulation’ 
we  mean  the  ability  to  introduce  logical  terms,  pass  them  as  arguments  to  functions,  emit  them  as  results 
from  functions  and  also  pattern  match  on  their  structure  programmatically.  By  ‘typed  manipulation’  we 
mean  that  the  logical-level  typing  information  of  logical  terms  is  retained  during  such  manipulation.  By 
‘type-safe’  we  mean  that  subject  reduction  holds  for  the  programming  language.  By  ‘general-purpose  side- 
effectful  programming  model’  we  mean  a  programming  model  that  includes  at  the  very  least  datatypes, 
general  recursion  and  mutable  references.  We  choose  the  core  ML  calculus  to  satisfy  this  requirement.  We 
demonstrate  theoretical  possibility  by  designing  a  type  system  and  operational  semantics  for  this  program¬ 
ming  language  and  establishing  its  metatheory.  We  demonstrate  practical  implementability  through  an 
extensive  prototype  implementation  of  the  language,  which  is  sufficiently  efficient  in  order  to  test  various 
examples  in  the  language.  We  demonstrate  viability  as  a  proof  assistant  by  implementing  a  set  of  examples 
tactics  and  proofs  in  the  language.  We  demonstrate  the  fact  that  this  language  offers  improvements  over 
current  proof  assistant  architectures  by  showing  that  it  enables  user-extensible  static  checking  of  proofs 
and  tactics  and  utilizing  such  support  in  our  examples.  We  demonstrate  how  this  support  simplifies  com¬ 
plex  implementations  of  similar  examples  in  traditional  proof  assistants. 

1.3  Summary  of  results 

In  this  section  I  present  the  technical  results  of  my  dissertation  research. 

1.  Formal  design  of  VeriML.  I  have  developed  a  type  system  and  operational  semantics  supporting  a 
combination  of  general-purpose,  side-effectful  programming  with  first-class  typed  support  for  log¬ 
ical  term  manipulation.  The  support  for  logical  terms  allows  specifying  the  input-output  behavior 
of  functions  that  manipulate  logical  terms.  The  language  includes  support  for  pattern  matching 
over  open  logical  terms,  as  well  as  over  variable  environments.  The  type  system  works  by  leverag¬ 
ing  contextual  type  theory  for  representing  open  logical  terms  as  well  as  the  variable  environments 
they  depend  on.  I  also  show  a  number  of  extensions  to  the  core  language,  such  as  a  simple  staging 
construct  and  a  proof  erasure  procedure. 
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2.  Metatheory.  I  have  proved  a  number  of  metatheoretic  results  for  the  above  language. 

Type  safety  ensures  that  a  well-typed  expression  of  the  language  evaluates  to  a  well-typed  value  of 
the  same  type,  in  the  case  where  evaluation  is  successful  and  terminates.  This  is  crucial  in 
ensuring  that  the  type  that  is  statically  assigned  to  an  expression  can  be  trusted.  For  example, 
it  follows  that  expressions  whose  static  type  claims  that  a  proof  for  a  specific  proposition  will 
be  created  indeed  produce  such  a  proof  upon  successful  evaluation. 

Type  safety  for  static  evaluation  ensures  that  the  extension  of  the  language  with  the  staging  con¬ 
struct  for  static  evaluation  of  expressions  obeys  the  same  safety  principle. 

Compatibility  of  normal  and  proof-erasure  semantics  establishes  that  every  step  in  the  evalua¬ 
tion  of  a  source  expression  that  has  all  proof  objects  erased  corresponds  to  a  step  in  the  evalu¬ 
ation  of  the  original  source  expression.  This  guarantees  that  even  if  we  choose  not  to  generate 
proof  objects  while  evaluating  expressions  of  the  language,  valid  proof  objects  of  the  right 
type  always  exist.  Thus,  if  users  are  willing  to  trust  the  type  checker  and  runtime  system  of 
VeriML,  they  can  use  the  optimized  semantics  where  no  proof  objects  get  created. 

Collapsing  transformation  of  contextual  terms  establishes  that  under  reasonable  limitations  with 
respect  to  the  definition  and  use  of  contextual  variables,  a  contextual  term  can  be  transformed 
into  one  that  does  not  mention  such  contextual  variables.  This  proof  provides  a  way  to  trans¬ 
form  proof  expressions  inside  tactics  into  static  proof expressions  evaluated  statically,  at  the  time 
that  the  tactic  is  defined,  using  staging. 

3.  Prototype  implementation.  I  have  developed  a  prototype  implementation  of  VeriML  in  OCaml, 
which  is  used  to  type  check  and  evaluate  a  wide  range  of  examples.  The  prototype  has  an  extensive 
feature  set  over  the  pure  language  as  described  formally,  supporting  type  inference,  surface  syntax 
for  logical  terms  and  VeriML  code,  special  tactic  syntax  and  translation  to  simply-typed  OCaml 
code. 

4.  Extensible  conversion  rule.  We  showcase  how  VeriML  can  be  used  to  solve  the  long-standing 
problem  of  a  user-extensible  conversion  rule.  The  conversion  rule  that  we  describe  combines  the 
following  characteristics:  it  is  safe,  meaning  that  it  preserves  logical  soundness;  it  is  user-extensible, 
using  a  familiar,  generic  programming  model;  and,  it  does  not  require  metatheoretic  additions  to  the 
logic,  but  can  be  used  to  simplify  the  logic  instead.  Also,  we  show  how  this  conversion  rule  enables 
receivers  of  a  formal  proof  to  choose  the  exact  size  of  the  trusted  core  of  formal  proof  checking;  this 
choice  is  traditionally  only  available  at  the  time  that  a  logic  is  designed.  We  believe  this  is  the  first 
technique  that  combines  these  characteristics  leading  to  a  safe  and  user-extensible  static  checking 
technique  for  proofs. 

5.  Static  proof  expressions.  I  describe  a  method  that  enables  discovery  and  proof  of  required  lem¬ 
mas  within  tactics.  This  method  requires  minimal  programmer  annotation  and  increases  the  static 
guarantees  provided  by  the  tactics,  by  removing  potential  sources  of  errors.  I  showcase  how  the 
same  method  can  be  used  to  separate  the  proof-related  aspect  of  writing  a  new  tactic  from  the 
programming-related  aspect,  leading  to  increased  separation  of  concerns. 

6.  Dependently  typed  programming.  I  also  show  how  static  proof  expressions  can  be  useful  in  tradi¬ 
tional  dependently-typed  programming  (in  the  style  of  Dependent  ML  [Xi  and  Pfenning,  1999]  and 
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Agda  [Norell,  2007]),  exactly  because  of  the  increased  separation  of  concerns  between  the  program¬ 
ming  and  the  proof-related  aspects.  By  combining  this  with  the  support  for  writing  automation 
tactics  within  VeriML,  we  show  how  our  language  enables  a  style  of  dependently-typed  program¬ 
ming  where  the  extra  proof  obligations  are  generated  and  resolved  within  the  same  language. 

7.  Technical  advances  in  metatheoretic  techniques.  The  metatheory  for  VeriML  that  I  have  de¬ 
veloped  includes  a  number  of  technical  advances  over  developments  for  similar  languages  such  as 
Delphin  or  Beluga.  These  are: 

-  Orthogonality  between  logic  and  computation.  The  theorems  that  we  prove  about  the  computa¬ 
tional  language  do  not  depend  on  specifics  of  the  logic  language,  save  for  a  number  of  standard 
theorems  about  it.  These  theorems  establish  certain  substitution  and  weakening  lemmas  for 
the  logic  language,  as  well  as  the  existence  of  an  effective  pattern  matching  procedure  for  terms 
of  this  language.  This  makes  the  metatheory  of  the  computational  language  modular  with  re¬ 
spect  to  the  logic  language,  enabling  us  to  extend  or  even  replace  the  logic  language  in  the 
future. 

-  Hybrid  deBruijn  variable  representation.  We  use  a  concrete  variable  representation  for  vari¬ 
ables  of  the  logic  language  instead  of  using  the  named  approach  for  variables.  This  elucidates 
the  definitions  of  the  various  substitution  forms,  especially  wih  respect  to  substitution  of  a 
polymorphic  context  with  a  concrete  one;  it  also  makes  for  precise  substitution  lemma  state¬ 
ments.  It  is  also  an  efficient  implementation  technique  for  variables  and  enables  subtyping 
based  on  context  subsumption.  Using  the  same  technique  for  variable  representation  in  the 
metatheory  and  in  the  actual  implementation  of  the  language  decreases  the  trust  one  needs 
to  place  in  their  correspondence.  Last,  this  representation  opens  up  possibilities  for  further 
extensions  to  the  language,  such  as  multi-level  contextual  types  and  explicit  substitutions. 

-  Pattern  matching.  We  use  a  novel  technique  for  type  assignment  to  patterns  that  couples  our 
hybrid  variable  representation  technique  with  a  way  to  identify  relevant  variables  of  a  pattern, 
based  on  our  notion  of  partial  variable  contexts.  This  leads  to  a  simple  and  precise  induc¬ 
tion  principle,  used  in  order  to  prove  the  existence  of  deterministic  pattern  matching  -  our 
key  theorem.  The  computational  content  of  this  theorem  leads  to  a  simple  pattern  matching 
algorithm. 

8.  Implementations  of  extended  conversion  rules.  We  describe  our  implementation  of  the  tradi¬ 
tional  conversion  rule  in  VeriML  as  well  as  various  extensions  to  it,  such  as  congruence  closure 
and  arithmetic  simplification.  Supporting  such  extensions  has  prompted  significant  metatheoretic 
and  implementation  additions  to  the  logic  in  past  work.  The  implementation  of  such  algorithms 
in  itself  in  existing  proof  assistants  has  required  a  mix  of  techniques  and  languages.  We  show  how 
the  same  extensions  can  be  achieved  without  any  metatheoretic  additions  to  the  logic  or  special  im¬ 
plementation  techniques  by  using  our  computational  language.  Furthermore,  our  implementations 
are  concise,  utilize  language  features  such  as  mutable  references  and  require  a  minimal  amount  of 
manual  proof  from  the  programmer. 

Part  of  the  results  of  this  dissertation  have  previously  been  published  in  Stampoulis  and  Shao  [2010] 
(ICFP  2010)  and  in  Stampoulis  and  Shao  [2012a]  (POPL  2012).  The  latter  publication  is  also  accompanied 
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by  an  extensive  Technical  Report  [Stampoulis  and  Shao,  2012b]  where  the  interested  reader  can  find  fully 
detailed  proofs  of  the  main  technical  results  that  we  present  in  Chapters  3  through  6. 
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Chapter  2 

Informal  overview 


In  this  chapter  I  am  going  to  present  a  high-level  picture  of  the  architecture  of  modern  proof  assistants, 
covering  the  basic  notions  involved  and  identifying  a  set  of  issues  with  this  architecture.  I  will  then  present 
the  high-level  ideas  behind  VeriML  and  how  they  address  the  issues.  I  will  show  the  correspondences 
between  the  traditional  notions  in  a  proof  assistant  and  their  counterpart  in  VeriML,  as  well  as  the  new 
possibilities  that  are  offered.  Last,  I  will  give  a  brief  overview  of  the  constructs  of  the  language. 

2.1  Proof  assistant  architecture 

2.1.1  Preliminary  notions 

Formal  logic.  A  formal  logic  is  a  mathematical  system  that  defines  a  collection  of  objects;  a  collection 
of  statements  describing  properties  of  these  objects,  called  propositions-,  as  well  as  the  means  to  establish 
the  validity  of  such  statements  (under  certain  hypotheses),  called  proofs  or  derivations.  Derivations  are 
composed  by  using  axioms  and  logical  rules.  Axioms  are  a  collection  of  propositions  that  are  assumed 
to  be  always  valid;  therefore  we  always  possess  valid  proofs  for  them.  Logical  rules  describe  under  what 
circumstances  a  collection  of  proofs  for  certain  propositions  (the  premises)  can  be  used  to  establish  a  proof 
for  another  proposition  (the  consequence).  A  derivation  is  thus  a  recording  of  a  number  of  logical  steps, 
claiming  to  establish  a  proposition;  it  is  valid  if  every  step  is  an  axiom  or  a  valid  application  of  a  logical 
rule1. 

Proof  object;  proof  checker.  A  mechanized  logic  is  an  implementation  of  a  specific  formal  logic  as  a 
computer  system.  This  implementation  at  the  very  least  consists  of  a  way  to  represent  the  objects,  the 
propositions  and  the  derivations  of  the  logic  as  computer  data,  and  also  of  a  procedure  that  checks  whether 
a  claimed  proof  is  indeed  a  valid  proof  for  a  specific  proposition,  according  to  the  logical  rules.  We  refer 
to  the  machine  representation  of  a  specific  logical  derivation  as  the  proof  object,  the  computer  code  that 
decides  the  validity  of  proof  objects  is  called  the  proof  checker.  We  use  this  latter  term  in  order  to  signify 
the  trusted  core  of  the  implementation  of  the  logic:  bugs  in  this  part  of  the  implementation  might  lead  to 
invalid  proofs  being  admitted,  destroying  the  logical  soundness  of  the  overall  system. 

1.  Note  that  these  definitions  are  not  normative  and  can  be  generalized  in  various  ways,  but  they  will  suffice  for  the  purposes 
of  our  discussion. 
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Figure  2.1:  Basic  architecture  of  proof  assistants 

Proof  assistant.  A  mechanized  logic  automates  the  process  of  validating  formal  proofs,  but  does  not 
help  with  actually  developing  such  proofs.  This  is  what  a  proof  assistant  is  for.  Examples  of  proof  assis¬ 
tants  include  Coq  [Barras  et  ah,  2012],  Isabelle  [Paulson,  1994],  HOL4  [Slind  and  Norrish,  2008],  HOL- 
Light  [Harrison,  1996],  Matita  [Asperti  et  ah,  2007],  Twelf  [Pfenning  and  Schtirmann,  1999],  NuPRL 
[Constable  et  ah,  1986],  PVS  [Owre  et  ah,  1996]  and  ACL2  [Kaufmann  and  Strother  Moore,  1996],  Each 
proof  assistant  supports  a  different  logic,  follows  different  design  principles  and  offers  different  mecha¬ 
nisms  for  developing  proofs.  For  the  purposes  of  our  discussion,  the  following  general  architecture  for  a 
proof  assistant  will  suffice  and  corresponds  to  many  of  the  above-mentioned  systems.  A  proof  assistant 
consists  of  a  logic  implementation  as  described  above,  a  library  of  proof -producing  functions  and  a  language 
for  writing  proof  scripts  and  proof-producing  functions.  We  will  give  a  basic  description  of  the  latter  two 
terms  below  and  present  some  notable  examples  of  such  proof  assistants  as  well  as  important  variations  in 
the  next  section. 

Proof-producing  functions.  The  central  idea  behind  proof  assistants  is  that  instead  of  writing  proof 
objects  directly,  we  can  make  use  of  specialized  functions  that  produce  such  proof  objects.  By  choosing 
the  right  functions  and  composing  their  results,  we  can  significantly  cut  down  on  the  development  effort 
for  large  proofs.  We  refer  to  such  functions  as  proof-producing  functions  and  we  characterize  their  defini¬ 
tion  as  follows:  functions  that  manipulate  data  structures  involving  logical  terms,  such  as  propositions  and 
proofs,  and  produce  other  such  data  structures.  This  definition  is  deliberately  very  general  and  can  refer 
to  a  very  large  class  of  functions.  They  range  from  simple  functions  that  correspond  to  logical  reasoning 
principles  to  sophisticated  functions  that  perform  automated  proof  search  for  a  large  set  of  problems  uti¬ 
lizing  complicated  data  structures  and  algorithms.  Users  are  not  limited  to  a  fixed  set  of  proof-producing 
functions,  as  most  proof  assistants  allow  users  to  write  new  proof-producing  functions  using  a  suitable 
language. 

A  conceptually  simple  class  of  proof-producing  functions  are  decision  procedures:  functions  that  can 
decide  the  provability  of  all  the  propositions  of  a  particular,  well-defined  theory.  For  example,  Gaussian 
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elimination  corresponds  to  a  decision  procedure  for  systems  of  linear  equations2.  Automated  theorem 
provers  are  functions  that  attempt  to  discover  proofs  for  arbitrary  propositions,  taking  into  account  new 
definitions  and  already-proved  theorems;  the  main  difference  with  decision  procedures  being  that  the  class 
of  propositions  they  can  handle  is  not  defined  a  priori  but  is  of  an  ad  hoc  nature.  Automated  provers  might 
employ  sophisticated  algorithms  and  data  structures  in  order  to  discover  such  proofs.  Another  example 
is  rewriters,  functions  that  simplify  terms  and  propositions  into  equivalent  ones,  while  also  producing  a 
proof  witnessing  this  equivalence. 

A  last  important  class  of  proof-producing  functions  are  tactics.  A  tactic  is  a  proof-producing  function 
that  works  on  incomplete  proofs:  a  specific  data  structure  which  corresponds  to  a  ‘proof-in-development’ 
where  some  parts  might  still  be  missing.  A  tactic  accepts  an  incomplete  proof  and  transforms  it  into 
another  potentially  still  incomplete  proof;  furthermore,  it  provides  some  justification  why  the  transfor¬ 
mation  is  valid.  The  resulting  incomplete  proof  is  expected  to  be  simpler  to  complete  than  the  original 
one.  Every  missing  part  is  characterized  by  a  set  of  hypotheses  and  by  its  goal  -  the  proposition  we  need 
to  prove  in  order  to  fill  it  in;  we  refer  to  the  overall  description  of  the  missing  parts  as  the  current  proof 
state.  Examples  of  tactics  are:  induction  principles  -  where  a  specific  goal  is  changed  into  a  set  of  goals 
corresponding  to  each  case  of  an  inductive  type  with  extra  induction  hypotheses;  decision  procedures  and 
automated  provers  as  described  above;  and  higher-order  tactics  for  applying  a  tactic  everywhere  -  e.g., 
given  an  automated  prover,  try  to  finish  an  incomplete  proof  by  applying  the  prover  to  all  open  goals. 
The  notion  of  tactics  is  a  very  general  one  and  can  encompass  most  proof-producing  functions  that  are  of 
interest  to  users3.  Tactics  thus  play  a  central  role  in  many  current  proof  assistants. 

Proof  scripts.  If  we  think  of  proof  objects  as  a  low-level  version  of  a  formal  proof,  then  proof  scripts  are 
their  high-level  equivalent.  A  proof  script  is  a  program  which  composes  several  proof-producing  functions 
together.  When  executed,  a  proof  script  emits  a  proof  object  for  a  specific  proposition;  the  resulting  proof 
object  can  then  be  validated  through  the  proof  checker,  as  shown  in  Figure  2.1.  This  approach  to  proof 
scripts  and  their  validation  procedure  is  the  heart  of  many  modern  proof  assistants. 

Proof  scripts  are  written  in  a  language  that  is  provided  as  part  of  the  proof  assistant  and  follows  one 
of  two  styles:  the  imperative  style  or  the  declarative  style.  In  the  imperative  style,  the  focus  is  placed  on 
which  proof-producing  functions  are  used:  the  language  is  essentially  special  syntax  for  directly  calling 
proof-producing  functions  and  composing  their  results.  In  the  declarative  style,  the  focus  is  placed  on 
the  intermediate  steps  of  the  proof:  the  language  consists  of  human-readable  reasoning  steps  (e.g.  split 
by  these  cases,  know  that  a  certain  proposition  holds,  etc.).  A  default  proof-producing  function  is  used 
to  justify  each  such  step,  but  users  can  explicitly  specify  which  proof-producing  function  is  used  for  each 
step.  In  general,  the  imperative  style  is  significantly  more  concise  than  the  declarative  style,  at  the  expense 
of  being  ‘write-only’  -  meaning  that  it  is  usually  hard  for  a  human  to  follow  the  logical  argument  made  in 
an  imperative  proof  script  after  it  has  been  written. 

In  both  cases,  the  amount  of  detail  that  needs  to  be  included  in  a  proof  script  directly  depends  on 
the  proof-producing  functions  that  are  available.  This  is  why  it  is  important  to  be  able  to  write  new 
proof-producing  functions.  When  we  work  in  a  specific  domain,  we  might  need  functions  that  better  cor- 

2.  More  accurately:  for  propositions  that  correspond  to  systems  of  linear  equations. 

3.  In  fact,  the  term  ‘tactic’  is  more  established  than  ‘proof-producing  function’  and  is  often  used  even  in  cases  where  the  latter 
term  would  be  more  accurate.  We  follow  this  tradition  in  later  chapters  of  this  dissertation,  using  the  two  terms  interchangeably. 
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respond  to  the  reasoning  principles  for  that  domain;  we  can  even  automate  proof  search  for  a  large  class 
of  propositions  of  that  domain  through  a  specialized  algorithm.  In  this  way  we  can  cover  cases  where 
the  generic  proof  search  strategies  (offered  by  the  existing  proof  procedures)  do  not  perform  well.  One 
example  would  be  deciding  whether  two  polynomials  are  equivalent  by  attempting  to  use  normal  arith¬ 
metic  properties  in  a  fixed  order,  until  the  two  polynomials  take  the  same  form  -  instead  of  a  specialized 
equivalence  checking  procedure. 

In  summary,  a  proof  assistant  enables  users  to  develop  valid  formal  proofs  for  certain  propositions,  by 
writing  proof  scripts,  utilizing  an  extensible  set  of  proof-producing  functions  and  validating  the  resulting 
proof  objects  through  a  proof  checker.  In  the  next  section  we  will  see  examples  of  such  proof  assistants  as 
well  as  additions  to  this  basic  architecture.  As  we  will  argue  in  detail  below,  the  main  drawback  of  current 
proof  assistants  is  that  the  language  support  available  for  writing  proof-producing  functions  is  poor.  This 
hurts  the  extensibility  of  current  proof  assistants  considerably.  The  main  object  of  the  language  presented 
in  this  dissertation  is  to  address  exactly  this  fact. 

2.1.2  Variations 
LCF  family 

The  Edinburgh  LCF  system  [Gordon  et  ah,  1979]  was  the  first  proof  assistant  that  introduced  the  idea  of  a 
meta-language  for  programming  proof-producing  functions  and  proof  scripts.  A  number  of  modern  proof 
assistants,  most  notably  HOL4  [Slind  and  Norrish,  2008]  and  HOL-Light  [Harrison,  1996],  follow  the 
same  design  ideas  as  the  original  LCF  system  other  than  the  specific  logic  used  (higher-order  logic  instead 
of  Scott’s  logic  of  computable  functions).  Furthermore,  ML,  the  meta-language  designed  for  the  original 
LCF  system  became  important  independently  of  this  system;  modern  dialects  of  this  language,  such  as 
Standard  ML,  OCaml  and  F#  enjoy  wide  use  today.  An  interesting  historical  account  of  the  evolution  of 
LCF  is  provided  by  Gordon  [2000] . 

The  unique  characteristic  of  proof  assistants  in  the  LCF  family  is  that  the  same  language,  namely  ML, 
is  used  both  for  the  implementation  of  the  proof  assistant  and  by  the  user.  The  design  of  the  programming 
constructs  available  in  ML  was  very  much  guided  by  the  needs  of  writing  proof-producing  functions  and 
are  thus  very  well-suited  to  this  task.  For  example,  a  notion  of  algebraic  data  types  is  supported  so  that  we 
can  encode  sophisticated  data  structures  such  as  the  logical  propositions  and  the  ‘incomplete  proofs’  that 
tactics  manipulate;  general  recursion  and  pattern  matching  provide  a  good  way  to  work  with  these  data 
structures;  higher-order  functions  are  used  to  define  tacticals  -  functions  that  combine  tactics  together; 
exceptions  are  used  in  proof-producing  functions  that  might  fail;  and  mutable  references  are  crucial  in 
order  to  implement  various  efficient  algorithms  that  depend  on  an  imperative  programming  model. 

Proof  scripts  are  normal  ML  expressions  that  return  values  of  a  specific  proof  data  type.  We  can  use 
decision  procedures,  tactics  and  tacticals  provided  by  the  proof  assistant  as  part  of  those  proof  scripts  or 
we  can  write  new  functions  more  suitable  to  the  domain  we  are  interested  in.  We  can  also  define  further 
classes  of  proof-producing  functions  along  with  their  associated  data  structures:  for  example,  we  can  define 
an  alternate  notion  of  incomplete  proofs  and  an  associated  notion  of  tactics  that  are  better  suited  to  the 
declarative  proof  style,  if  we  prefer  that  style  instead  of  the  imperative  style  offered  by  the  proof  assistant. 

The  key  technical  breakthrough  of  the  original  Edinburgh  LCF  system  is  its  approach  to  ensuring 
that  only  valid  proofs  are  admitted  by  the  system.  Having  been  developed  in  a  time  where  memory  space 
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was  limited,  the  approach  of  storing  large  proof  objects  in  memory  and  validating  them  post-hoc  as  we  de¬ 
scribed  in  the  previous  section  was  infeasible.  The  solution  was  to  introduce  an  abstract  data  type  of  valid 
proofs.  Values  of  this  type  can  only  be  introduced  through  a  fixed  set  of  constructor  functions:  each  func¬ 
tion  consumes  zero  or  more  valid  proofs,  produces  another  valid  proof  and  is  in  direct  correspondence 
to  an  axiom  or  rule  of  the  original  logic4.  Expressions  having  the  type  of  valid  proofs  are  guaranteed  to 
correspond  to  a  derivation  in  the  original  logic  when  evaluated  -  save  for  failing  to  evaluate  successfully 
(i.e.  if  they  go  into  an  infinite  loop  or  throw  an  exception).  This  correspondence  is  direct  in  the  case 
where  such  expressions  are  formed  by  combining  calls  to  the  constructor  functions.  The  careful  design 
of  the  type  system  of  ML  guarantees  that  such  a  correspondence  continues  to  hold  even  when  using  all 
the  sophisticated  programming  constructs  available.  Formally,  this  guarantee  is  a  direct  corollary  of  the 
type-safety  theorem  of  the  ML  language,  which  establishes  that  any  expression  of  a  certain  type  evaluates 
to  a  value  of  that  same  type,  or  fails  as  described  above. 

The  ML  type  system  is  expressive  enough  to  describe  interesting  data  structures  as  well  as  the  signa¬ 
tures  of  functions  such  as  decision  procedures  and  tactics,  describing  the  number  and  type  of  arguments 
they  expect.  For  example,  the  type  of  a  decision  procedure  can  specify  that  it  expects  a  proposition  as  an 
input  argument  and  produces  a  valid  proof  as  output.  Yet,  we  cannot  specify  that  the  resulting  proof  actu¬ 
ally  proves  the  given  proposition.  The  reason  is  that  all  valid  proofs  are  identified  at  the  level  of  types.  We 
cannot  capture  finer  distinctions  of  proofs  in  the  type  system,  specifying  for  example  that  a  proof  proves 
a  specific  proposition,  or  a  proposition  that  has  a  specific  structure.  All  other  logical  terms  (e.g.  propo¬ 
sitions,  natural  numbers,  etc.)  are  also  identified.  Thus  the  signatures  that  we  give  to  proof-producing 
functions  do  not  fully  reflect  the  input -output  relationships  of  the  logical  terms  involved.  Because  of  the 
identification  of  the  types  of  logical  terms,  we  say  that  proof-producing  functions  are  programmed  in  an 
essentially  untyped  manner.  By  extension,  the  same  is  true  of  proof  scripts. 

This  is  a  severe  limitation.  It  means  that  no  information  about  logical  terms  is  available  at  the  time 
when  the  user  is  writing  functions  or  proof  scripts,  information  which  would  be  useful  to  the  user  and 
could  also  be  used  to  prevent  errors  at  the  time  of  function  or  proof  script  definition  -  statically.  Instead, 
all  logic-related  errors,  such  as  proving  the  wrong  proposition  or  using  a  tactic  in  a  case  where  it  does  not 
apply,  will  only  be  caught  when  (and  if)  evaluation  reaches  that  point  -  dynamically.  This  is  a  profound 
issue  especially  in  the  case  of  proof-producing  functions,  where  logic-related  errors  might  be  revealed 
unexpectedly  at  a  particular  invocation  of  the  function.  Also,  in  the  case  of  imperative  proof  scripts,  this 
limitation  precludes  us  from  knowing  how  the  proof  state  evolves  -  as  no  information  about  the  input 
and  output  proof  state  of  the  tactics  used  is  available  statically.  The  user  has  to  keep  a  mental  model  of  the 
evolution  of  proof  state  in  order  to  write  proof  scripts  that  evaluate  successfully. 

Overall,  the  architecture  of  proof  assistants  in  this  family  is  remarkably  simple  yet  leads  to  a  very  exten¬ 
sible  and  flexible  proof  development  style.  Users  have  to  master  a  single  language  where  they  can  mix 
development  of  proofs  and  development  of  specialized  proof-producing  functions,  employing  a  general- 
purpose  programming  model.  The  main  shortcoming  is  that  all  logic-related  programming  (whether  it  be 

4.  This  is  the  main  departure  compared  to  the  picture  given  in  the  previous  section,  as  the  logic  implementation  does  not 
include  explicit  proof  objects.  Instead,  proof  object  generation  is  essentially  combined  with  proof  checking,  rendering  the  full 
details  of  the  proof  object  irrelevant.  We  only  need  to  retain  information  about  the  proposition  that  it  proves  in  order  to  be  able 
to  form  further  valid  proofs.  Based  on  this  correspondence,  it  is  easy  to  see  that  the  core  of  the  proof  checker  is  essentially  the 
set  of  valid  proof  constructor  functions. 
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proof  scripts  or  proof-producing  functions)  is  essentially  done  in  an  untyped  manner. 

Isabelle 

Isabelle  [Paulson,  1994]  is  a  widely  used  proof  assistant  which  evolved  from  the  LCF  tradition.  The  main 
departure  from  the  LCF  design  is  that  instead  of  being  based  on  a  specific  logic,  its  logical  core  is  a  logical 
framework  instead.  Different  logics  can  then  be  implemented  on  top  of  this  basic  logical  framework.  The 
proof  checker  is  then  understood  as  the  combination  of  the  implementation  of  the  base  logical  framework 
and  of  the  definition  of  the  particular  logic  we  work  with.  Though  this  design  allows  for  flexibility  in 
choosing  the  logic  to  work  with,  in  practice  the  vast  majority  of  developments  in  Isabelle  are  done  using 
an  encoding  of  higher-order  logic,  similar  to  the  one  used  in  HOL4  and  HOL-Light.  This  combination  is 
referred  to  as  Isabelle/HOL  [Nipkow  et  ah,  2002], 

The  main  practical  benefit  that  Isabelle  offers  over  proof  assistants  following  the  LCF  tradition  is 
increased  interactivity  when  developing  proof  scripts.  Though  interactivity  support  is  available  in  some 
LCF  proof  assistants,  it  is  emphasized  more  in  the  case  of  Isabelle.  The  proof  assistant  is  able  to  run  a 
proof  script  up  to  a  specified  point  and  inform  the  user  of  the  proof  state  at  that  point  -  the  remaining 
goals  that  need  to  be  proved  and  the  hypotheses  at  hand.  The  user  can  then  continue  developing  the  proof 
script  based  on  that  information.  Proof  scripts  are  therefore  developed  in  a  dialog  with  the  proof  assistant 
where  the  evolution  of  proof  state  is  clearly  shown  to  the  user:  the  user  starts  with  the  goal  they  want 
to  prove,  chooses  an  applicable  tactic  and  gets  immediate  feedback  about  the  new  subgoals  they  need  to 
prove.  This  process  continues  until  a  full  proof  script  is  developed  and  no  more  subgoals  remain. 

This  interactivity  support  is  made  possible  in  Isabelle  by  following  a  two-layer  architecture.  The 
first  layer  consists  of  the  implementation  of  the  proof  assistant  in  the  classic  LCF  style,  including  the 
library  of  tactics  and  other  proof-producing  functions,  using  a  dialect  of  ML.  It  also  incorporates  the 
implementation  of  a  higher-level  language  which  is  specifically  designed  for  writing  proof  scripts;  and  of  a 
user  interface  providing  interactive  development  support  for  this  language  as  described  above.  The  second 
layer  consists  of  proof  developments  done  using  the  higher-level  language.  Unless  otherwise  necessary, 
users  work  at  this  layer. 

The  split  into  two  layers  de-emphasizes  the  support  for  writing  new  proof-producing  functions  using 
ML.  Writing  a  new  tactic  comes  with  the  extra  overhead  of  having  to  learn  the  internal  layer  of  the  proof 
assistant.  This  difficulty  is  added  on  top  of  the  issues  with  the  development  of  proof-producing  functions 
as  in  the  normal  LCF  case.  Rather  than  writing  their  own  specialized  tactics  to  automate  domain-specific 
details,  users  are  thus  more  likely  to  use  already-existing  tactics  for  proving  these  details.  This  leads  to 
longer  proof  scripts  that  are  less  robust  to  small  changes  in  the  definitions  involved. 

In  Isabelle,  this  issue  is  minimized  through  the  use  of  a  powerful  simplifier  -  an  automation  mechanism 
that  rewrites  propositions  into  simpler  forms.  It  makes  use  of  a  rule  for  higher-order  unification  which  is 
part  of  the  core  logical  theory  of  Isabelle.  We  can  think  of  the  simplifier  as  a  specific  proof-producing 
function  which  is  utilized  by  most  other  tactics  and  decision  procedures.  Users  can  extend  the  simplifier 
by  registering  rewriting  first-order  lemmas  with  it.  The  lemmas  are  proved  normally  using  the  interactive 
proof  development  support.  This  is  an  effective  way  to  add  domain-specific  automation  with  a  very 
low  cost  to  the  user,  while  making  use  of  the  primary  workload  that  Isabelle  was  designed  to  optimize. 
We  refer  to  the  simplifier  as  a  small-scale  automation  mechanism:  it  is  used  ubiquitously  and  implicitly 
throughout  the  proof  development  process.  We  thus  differentiate  similar  mechanisms  from  the  large-scale 
automation  offered  through  the  use  of  tactics. 
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Still,  the  automation  support  that  can  be  added  through  the  simplifier  is  quite  limited  when  compared 
to  the  full  ML  programming  model  available  when  writing  new  tactics.  As  mentioned  above,  we  can  only 
register  first-order  lemmas  with  the  simplifier.  These  correspond  roughly  to  the  Horn  clauses  composing 
a  program  in  a  logic  programming  language  such  as  Prolog.  The  simplifier  can  then  be  viewed  as  an 
interpreter  for  that  language,  performing  proof  search  over  such  rules  using  a  fixed  strategy.  In  the  cases 
where  this  programming  model  cannot  capture  the  automation  we  want  to  support  (e.g.  when  we  want 
to  use  an  efficient  algorithm  that  uses  imperative  data  structures),  we  have  to  fall  back  to  developing  a  new 
tactic. 

Coming  back  to  proof  scripts,  there  is  one  subtle  issue  that  we  did  not  discuss  above.  As  we  mentioned, 
being  able  to  evaluate  proof  scripts  up  to  some  point  is  a  considerable  benefit.  Even  with  this  support, 
proof  scripts  still  leave  something  to  be  desired,  which  becomes  more  apparent  by  juxtaposing  them  with 
proof  objects.  Every  sub-part  of  a  proof  object  corresponds  to  a  derivation  in  itself  and  has  a  clearly 
defined  set  of  prerequisites  and  conclusions,  based  on  the  logical  rules.  Proof  scripts,  on  the  other  hand, 
do  not  have  a  similar  property.  Every  sub-part  of  a  proof  script  critically  depends  on  the  proof  state 
precisely  before  that  sub-part  begins.  This  proof  state  cannot  be  determined  save  for  evaluating  the  proof 
script  up  to  that  point;  there  is  no  way  to  identify  the  general  circumstances  under  which  that  sub-part  of 
the  proof  script  applies.  This  hurts  the  composability  of  proof  scripts,  precluding  isolation  of  interesting 
parts  to  reuse  in  other  situations. 

Coq 

Coq  [Bertot  et  ah,  2004]  is  considered  to  be  the  current  state-of-the-art  proof  assistant  stemming  from  the 
LCF  tradition.  It  has  a  wide  variety  of  features  over  proof  assistants  such  as  HOL  and  Isabelle:  it  uses 
CIC  [Coquand  and  Huet,  1988,  Werner,  1994]  as  its  logical  theory,  which  is  a  version  of  Martin-Lof  type 
theory  [Martin-Lof,  1984]  and  enables  the  encoding  of  mathematical  results  that  are  not  easily  expressible 
in  HOL;  it  supports  the  extraction  of  computational  content  out  of  proofs,  resulting  in  programs  that  are 
correct  by  construction,  by  exploiting  the  Curry-Howard  isomorphism;  and  it  supports  a  rich  notion 
of  inductive  and  coinductive  datatypes.  Since  our  main  focus  is  the  extensibility  of  proof  assistants  with 
respect  to  automation  for  new  domains,  we  will  not  focus  on  these  features,  as  they  do  not  directly  affect 
the  extensibility.  We  will  instead  focus  on  the  support  for  a  specialized  tactic  development  language, 
called  LTac;  the  inclusion  of  a  conversion  rule  in  the  core  logical  theory;  and  the  combined  use  of  these 
features  for  a  proof  technique  called  proof-by-reflection.  As  we  will  see,  Coq  allows  various  languages 
for  developing  tactics  and  other  automation  procedures;  Figure  2.2  summarizes  these,  shows  how  they 
are  combined  into  the  basic  architecture  of  Coq,  and  compares  between  them.  The  comparison  is  based 
around  three  factors: 

-  convenience,  based  on  the  presence  of  pattern  matching  and  other  specialized  constructs  specifi¬ 
cally  tailored  to  writing  proof-producing  procedures  vs.  the  requirement  to  use  general-purpose 
constructs  through  encodings 

-  the  presence  of  types  that  can  capture  logical  errors  inside  tactics  statically,  and 

-  expressivity,  depending  on  whether  a  full  programming  model  with  side-effects  and  data  types  can 
be  used. 
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Figure  2.2:  Programming  languages  available  for  writing  automation  procedures  in  the  Coq  architecture 

The  basic  architecture  of  Coq  follows  the  basic  description  of  the  previous  section,  as  well  as  the  two- 
layer  architecture  described  for  Isabelle.  The  implementation  layer  of  the  proof  assistant  is  programmed 
in  ML.  It  includes  an  explicit  notion  of  proof  objects  along  with  a  proof  checker  for  validating  them;  the 
implementation  of  basic  proof-producing  functions  and  tactics;  and  the  implementation  of  the  user-level 
language  along  with  an  interface  for  it.  Proof  scripts  written  in  this  language  make  calls  to  tactics  and 
ultimately  produce  proof  objects  which  are  then  validated.  Interactive  support  is  available  for  developing 
the  proof  scripts. 

The  user-level  language  for  proof  development  is  called  LTac  [Delahaye,  2000,  2002] .  It  includes  sup¬ 
port  not  only  for  writing  proof  scripts,  but  also  for  writing  new  tactics  at  a  higher  level  than  writing 
them  directly  in  ML.  LTac  provides  constructs  for  pattern  matching  on  propositions  (in  general  on  logi¬ 
cal  terms)  and  on  the  current  proof  state.  Defining  recursive  functions  and  calling  already  defined  tactics 
is  also  allowed.  In  this  way,  the  overhead  of  writing  new  tactics  is  lowered  significantly.  Thus  developing 
new  domain-specific  tactics  as  part  of  a  proof  development  effort  is  re-emphasized  and  is  widely  regarded 
to  be  good  practice  [Chlipala,  2007,  2011,  Morrisett  et  ah,  2012],  Yet  LTac  has  its  fair  share  of  problems. 
First  of  all,  the  programming  model  supported  is  still  limited  compared  to  writing  tactics  in  ML:  there  is 
no  provision  for  user-defined  data  structures  or  for  mutable  references.  Also,  LTac  is  completely  untyped 
-  both  with  respect  to  the  logic  (just  as  writing  tactics  in  ML  is),  but  also  with  respect  to  the  limited  data 
structure  support  that  there  is.  There  is  no  support  for  interactive  development  of  tactics  in  the  style 
supported  for  proof  scripts;  such  support  would  be  impossible  to  add  without  having  access  to  some  typ¬ 
ing  information.  Therefore  programming  tactics  using  LTac  is  at  least  as  error-prone  as  developing  them 
using  ML.  The  untyped  nature  of  the  language  makes  LTac  tactics  brittle  with  respect  to  small  changes 
in  the  involved  logical  definitions,  posing  significant  problems  in  the  maintenance  and  adaptation  of  tac¬ 
tics.  Furthermore,  LTac  is  interpreted.  The  interpretation  overhead  considerably  limits  the  performance 
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of  tactics  written  using  it.  Because  of  these  reasons,  developing  LTac  tactics  is  often  avoided  despite  the 
potential  benefits  that  it  can  offer  [Nanevski  et  ah,  2010], 

Another  variation  of  the  basic  architecture  that  is  part  of  the  Coq  proof  assistant  is  the  inclusion  of  a 
conversion  rule  in  its  logical  core.  Arguments  that  are  based  solely  on  computation  of  functions  defined 
in  the  logic,  such  as  the  fact  that  1  +  1  =  2,  are  ubiquitous  throughout  formal  proofs.  If  we  record  all 
the  steps  required  to  show  that  such  arguments  are  valid  as  part  of  the  proof  objects,  their  size  soon 
becomes  prohibitively  large.  It  has  been  argued  that  such  arguments  should  not  be  recorded  in  formal 
proofs  but  rather  should  be  automatically  decided  through  computation  -  a  principle  that  has  been  called 
the  Poincare  principle  [Barendregt  and  Geuvers,  1999],  Coq  follows  this  idea  through  the  conversion  rule 
-  a  small-scale  automation  mechanism  that  implicitly  decides  exactly  such  computational  equivalences. 
The  implementation  of  the  conversion  rule  needs  to  be  part  of  the  trusted  proof  checker.  Also,  because 
of  the  tight  integration  into  the  logical  core,  it  is  important  to  make  sure  that  the  equivalences  decided 
by  the  conversion  rule  cannot  jeopardize  the  soundness  of  the  logic.  Proving  this  fact  is  one  of  the  main 
difficulties  in  establishing  the  soundness  of  the  CIC  logic  that  Coq  is  based  on. 

At  the  same  time,  extensions  to  the  equivalences  that  can  be  decided  through  the  conversion  rule  are 
desirable.  The  reason  is  straightforward:  since  these  equivalences  are  decided  automatically  and  implicitly, 
users  do  not  have  to  explicitly  allude  to  a  tactic  in  order  to  prove  them  and  thus  the  proof  scripts  can 
be  more  concise5.  If  we  view  these  equivalences  as  trivial  steps  of  a  proof,  deciding  them  implicitly 
corresponds  accurately  to  the  informal  practice  of  omitting  them  from  our  proofs.  Therefore  we  would 
like  the  conversion  rule  to  implicitly  decide  other  trivial  details,  such  as  simple  arithmetic  simplifications, 
equational  reasoning  steps,  rearrangement  of  logical  connectives,  etc.  Such  extensions  to  the  conversion 
rule  supported  by  Coq  have  been  proposed  [Blanqui  et  ah,  1999,  2010]  and  implemented  as  part  of  the 
CoqMT  project  [Strub,  2010],  Furthermore,  the  NuPRL  proof  assistant  Constable  et  al.  [1986]  is  based 
on  a  different  variant  of  Martin-Lof  type  theory  which  includes  an  extensional  conversion  rule.  This 
enables  arbitrary  decision  procedures  to  be  added  to  conversion,  at  the  cost  of  having  to  include  all  of 
them  in  the  trusted  core  of  the  system. 

In  general,  extensions  to  the  conversion  rule  come  at  a  significant  cost:  considerable  engineering  effort 
is  required  in  order  to  change  the  internals  of  the  proof  assistant;  the  trusted  core  of  the  system  needs 
to  be  expanded  by  the  new  conversion  rule;  and  the  already  complex  metatheoretic  proofs  about  the 
soundness  of  the  CIC  logic  need  to  be  adapted.  It  is  especially  telling  that  the  relatively  small  extension 
of  ^-conversion,  a  form  of  functional  extensionality,  took  several  years  before  it  was  considered  logically 
safe  to  add  to  the  base  Coq  system  [Barras  et  ah,  2012],  Because  of  these  costs,  user  extensions  to  the 
conversion  rule  are  effectively  impossible. 

Still,  the  conversion  rule  included  in  Coq  is  powerful  enough  to  support  another  way  in  which  au¬ 
tomation  procedures  can  be  written,  through  the  technique  called  proof  by -reflection  [Boutin,  1997],  The 
main  idea  is  to  program  automation  procedures  directly  within  the  logic  and  then  utilize  the  conversion 
rule  in  order  to  evaluate  them.  As  described  earlier,  the  conversion  rule  can  decide  whether  two  logi¬ 
cal  terms  are  equivalent  up  to  evaluation  -  in  fact,  it  is  accurate  to  consider  the  implementation  of  the 
conversion  rule  as  a  partial  evaluator  for  the  functional  language  contained  within  the  logic.  We  refer  to 
this  language  as  Gallina,  from  the  name  of  the  language  used  to  write  out  proof  objects  and  other  logical 

5.  A  further  benefit  of  an  extended  conversion  rule  is  that  it  allows  more  terms  to  be  typed.  This  is  true  in  CIC  because  of  the 
inclusion  of  dependent  types  in  the  logical  theory.  We  will  focus  on  a  logic  without  dependent  types,  so  we  will  not  explore  the 
consequences  of  this  in  this  section.  We  refer  the  reader  to  Section  3.2  and  7. 1  for  more  details. 
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terms  in  Coq.  The  technique  works  as  follows:  we  reflect  the  set  of  propositions  we  want  to  decide  as  an 
inductive  datatype  in  the  logic;  we  develop  the  decision  procedure  in  Gallina,  as  a  function  that  works 
over  terms  of  that  datatype;  and  we  prove  that  the  decision  procedure  is  sound  -  that  is,  when  the  decision 
procedure  says  that  such  an  ‘inductive  proposition’  is  true,  the  original  proposition  it  corresponds  to  is 
also  provable.  Now,  a  simple  proof  object  which  just  calls  the  Gallina  decision  procedure  on  an  inductive 
proposition  can  serve  as  a  proof  for  the  original  proposition,  because  the  conversion  rule  will  implicitly 
evaluate  the  procedure  call.  Usually,  a  wrapper  LTac  tactic  is  written  that  finds  the  inductive  proposition 
corresponding  to  the  current  goal  and  returns  such  a  proof  object  for  it. 

The  proof-by-reflection  technique  leads  to  decision  procedures  that  are  correct  by  construction.  There 
is  a  clear  specification  of  the  proof  that  the  decision  procedure  needs  to  provide  in  each  case  -  the  propo¬ 
sition  corresponding  to  the  inductive  proposition  at  hand.  Thus  programming  using  proof-by-reflection 
is  typed  with  respect  to  logical  terms,  unlike  programming  decision  procedures  directly  in  ML.  For  this 
reason  decision  procedures  developed  in  this  style  have  much  better  maintainability  characteristics.  The 
bulk  of  the  development  of  a  decision  procedure  in  this  style  is  proving  its  soundness;  this  has  a  clear 
statement  and  can  be  proved  through  normal  proof  scripts,  making  use  of  the  interactive  proof  support. 
Last,  it  can  lead  to  fairly  efficient  decision  procedures.  This  is  true  both  because  large  proof  objects  do 
not  need  to  be  generated  thanks  to  the  conversion  rule,  and  also  because  we  can  use  a  fast  bytecode-  or 
compilation-based  backend  as  the  evaluation  engine  of  the  conversion  rule  [Gregoire  and  Leroy,  2002, 
Gregoire,  2003],  This  latter  choice  of  course  adds  considerable  complexity  to  the  trusted  core. 

On  the  other  hand,  the  technique  is  quite  involved  and  is  associated  with  a  high  overhead,  as  is  appar¬ 
ent  from  its  brief  description  above.  Reflecting  the  propositions  of  the  logic  as  an  inductive  type  within 
the  logic  itself,  as  well  as  the  encoding  and  decoding  functions  required,  is  a  costly  and  tedious  process. 
This  becomes  a  problem  when  we  want  to  reflect  a  large  class  of  propositions,  especially  if  this  class  in¬ 
cludes  propositions  with  binding  structure,  such  as  quantified  formulas.  The  biggest  problem  is  that  the 
programming  model  supported  for  writing  functions  in  Gallina  is  inherrently  limited.  Non-termination, 
as  arising  from  general  recursion,  and  any  other  kind  of  side-effectful  operation  is  not  allowed  as  part 
of  Gallina  programs.  Including  such  side-effects  would  destroy  the  logical  soundness  of  the  system  be¬ 
cause  the  conversion  rule  would  be  able  to  prove  invalid  equivalences.  Thus  when  we  want  to  encode 
an  algorithm  that  uses  imperative  data  structures  we  are  left  with  two  choices:  we  either  re-engineer  the 
algorithm  to  work  with  potentially  inefficient  functional  data  structures;  or  we  implement  the  algorithm 
in  ML  and  use  a  reflective  procedure  to  validate  the  results  of  the  algorithm  -  adding  a  third  language  into 
the  mix.  Various  tactics  included  in  Coq  utilize  this  latter  option. 

A  last  Coq  feature  of  note  is  the  inclusion  of  a  unification  engine  as  part  of  the  type  inference  algorithm 
for  logical  terms.  It  has  recently  been  shown  that  this  engine  can  be  utilized  to  provide  transparent 
automation  support,  through  a  mechanism  called  canonical  structures  [Gonthier  et  ah,  2011],  Matita 
[Asperti  et  ah,  2007],  a  proof  assistant  similar  to  Coq,  offers  the  related  mechanism  of  unification  hints 
[Asperti  et  ah,  2009],  This  technique  requires  writing  the  automation  procedure  as  a  logic  program. 
Therefore  the  issues  we  argued  above  for  the  Isabelle  simplifier  and  for  proof-by-reflection  also  hold  for 
this  technique. 

2.1.3  Issues 

We  will  briefly  summarize  the  issues  with  the  current  architecture  of  proof  assistants  that  we  have  identi¬ 
fied  in  the  discussion  above.  As  we  mentioned  in  the  introduction,  we  perceive  the  support  for  extending 
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the  available  automation  to  be  lacking  in  current  proof  assistants  -  both  with  respect  to  small-scale  and  to 
large-scale  automation.  This  ultimately  leads  to  long  proof  scripts  that  include  more  details  than  necessary 
and  limit  the  scalability  of  the  overall  proof  development  process.  More  precisely,  the  issues  we  have  seen 
are  the  following. 

1.  Proof-producing  functions  such  as  tactics  and  decision  procedures  are  programmed  in  an  essentially 
untyped  manner.  We  cannot  specify  the  circumstances  under  which  they  apply  and  what  proofs 
they  are  supposed  to  return.  Programming  such  functions  is  thus  error  prone  and  limits  their 
maintainability  and  composability. 

2.  No  helpful  information  is  offered  to  the  user  while  developing  such  functions,  for  example  in  a 
form  similar  to  the  interactive  development  of  proof  scripts. 

3.  Though  proof  scripts  can  be  evaluated  partially  in  modern  proof  assistants,  we  cannot  isolate  sub¬ 
parts  of  proof  scripts  in  order  to  reuse  them  in  other  situations.  This  is  due  to  their  implicit  de¬ 
pendence  on  the  current  proof  state  which  is  only  revealed  upon  evaluation.  There  is  no  way  to 
identify  their  general  requirements  on  what  the  proof  state  should  be  like. 

4.  The  programming  model  offered  through  small-scale  automation  mechanisms  is  limited  and  is  not 
a  good  target  for  many  automation  algorithms  that  employ  mutable  data  structures. 

5.  The  small-scale  automation  mechanisms  such  as  the  conversion  rule  are  part  of  the  core  imple¬ 
mentation  of  the  proof  assistant.  This  renders  user  extensions  to  their  functionality  practically 
impossible. 

6.  Users  have  to  master  a  large  set  of  techniques  and  different  programming  models  in  order  to  provide 
the  domain-specific  automation  they  desire. 

2.2  A  new  architecture:  VeriML 

In  this  dissertation  we  propose  a  new  architecture  for  proof  assistants  that  tries  to  address  the  problems 
identified  above.  The  new  architecture  is  based  on  a  new  programming  language  called  VeriML,  which  is 
used  as  a  proof  assistant.  The  essence  behind  the  new  architecture  is  to  move  the  proof  checker  inside  the 
type  system  of  the  meta-language,  so  that  proof  producing  functions  are  verified  once  and  fiorall,  at  the  time  of 
their  definition  -  instead  of  validating  the  proof  objects  that  they  produce  every  time  they  are  invoked.  We 
present  the  basic  idea  of  this  architecture  in  juxtaposition  to  the  traditional  proof  assistant  architecture  in 
Figure  2.3.  VeriML  addresses  the  problems  identified  above  as  follows: 

1.  VeriML  allows  type-safe  programming  of  proof-producing  functions.  This  is  achieved  through  a 
rich  type  system,  allowing  us  to  specify  the  relationships  between  input  and  output  logical  terms 
accurately. 

2.  VeriML  offers  rich  information  while  developing  proof-producing  functions  in  the  form  of  assump¬ 
tions  and  current  proof  goals,  similar  to  what  is  offered  in  interactive  proof  assistants  for  proof 
scripts. 
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Time  Traditional  proof  assistants  VeriML 


Figure  2.3:  Comparison  of  architecture  between  current  proof  assistants  and  VeriML 

3.  Proof  scripts  are  typed,  because  the  functions  they  use  are  typed.  Therefore  they  can  be  decomposed 
just  like  proof  objects;  their  type  makes  evident  the  situations  under  which  they  apply  and  the 
proposition  that  they  prove. 

4.  The  extra  typing  allows  us  to  support  small-scale  automation  mechanisms  that  are  extensible  through 
the  full  VeriML  programming  model.  We  demonstrate  this  through  a  new  approach  to  the  conver¬ 
sion  rule,  where  arbitrary  functions  of  a  certain  type  can  be  added  to  it.  The  type  of  these  functions 
specifies  that  they  return  a  valid  proof  of  the  equivalence  they  claim,  thus  making  sure  that  logical 
soundness  is  not  jeopardized. 

5.  Small-scale  automation  mechanisms  are  implemented  as  normal  VeriML  code;  new  mechanisms 
can  be  implemented  by  the  user.  We  regain  the  benefits  of  including  them  in  the  core  of  the  proof 
assistant  through  two  simple  language  constructs:  proof-erasure  and  staging  support.  Proof-erasure 
enables  us  to  regain  and  generalize  the  reduction  in  proof  object  size;  staging  enables  us  to  use  such 
mechanisms  ubiquitously  and  implicitly,  not  only  for  checking  proof  scripts,  but  tactics  as  well. 

6.  There  is  a  single  programming  model  that  users  have  to  master  which  is  general-purpose  and  allows 
side-effectful  programming  constructs  such  as  non-termination,  mutable  references  and  I/O. 

Furthermore,  the  language  can  potentially  be  used  for  other  applications  that  mix  computation  and  proof, 
which  cannot  easily  be  supported  by  current  proof  assistants.  One  such  example  is  certifying  compilation 
or  certifying  static  analysis. 
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VeriML  is  a  computational  language  that  manipulates  logical  terms  of  a  specific  logic.  It  includes  a  core 
language  inspired  by  ML  (featuring  algebraic  datatypes,  polymorphism,  general  recursion  and  mutable 
references),  as  well  as  constructs  to  introduce  and  manipulate  logical  terms.  Rich  typing  information 
about  the  involved  logical  terms  is  maintained  at  all  times.  The  computational  language  is  kept  separate 
from  the  logical  language:  logical  terms  are  part  of  the  computational  language  but  computational  terms 
never  become  part  of  the  logical  terms  directly.  This  separation  ensures  that  soundness  of  the  logic  is 
guaranteed  and  is  independent  of  the  specifics  of  the  computational  language. 

Let  us  now  focus  on  the  rich  typing  information  available  for  logical  terms.  First,  we  can  view  the 
rules  for  formation  of  propositions  and  domain  objects,  as  well  as  the  logical  rules  utilized  for  constructing 
proof  objects  as  a  type  system.  Each  logical  term  can  thus  be  assigned  a  type,  which  is  a  logical  term  in 
itself  -  for  example,  a  proof  object  has  the  proposition  it  proves  as  its  type.  Viewing  this  type  system  as  an 
‘object’  language,  the  computational  language  provides  constructs  to  introduce  and  manipulate  terms  of 
this  object  language;  their  computational-level  type  includes  their  logical-level  type.  An  example  would 
be  an  automated  theorem  prover  that  accepts  a  proposition  P  as  an  argument  (its  type  specifying  that  P 
needs  to  be  a  well-formed  proposition)  and  returns  a  proof  object  which  proves  that  specific  proposition 
(its  type  needs  to  be  exactly  P).  Since  the  type  of  one  term  of  the  object  language  might  depend  on  another 
term  of  the  same  language,  this  is  a  form  of  dependently  typed  programming. 

The  computational  language  treats  these  logical  terms  as  actual  runtime  data:  it  provides  a  way  to  look 
into  their  structure  through  a  pattern  matching  construct.  In  this  way,  we  can  implement  the  automated 
theorem  prover  by  looking  into  the  possible  forms  of  the  proposition  P  and  building  an  appropriate  proof 
object  for  each  case.  In  each  branch,  type  checking  ensures  that  the  type  of  the  resulting  proof  object 
matches  the  expected  type,  after  taking  into  account  the  extra  information  coming  from  that  branch. 
Thus  pattern  matching  is  dependently  typed  as  well. 

The  pattern-matching  constructs,  along  with  the  core  ML  computational  constructs,  allow  users  to 
write  typed  proof-producing  functions.  Based  on  their  type,  we  clearly  know  under  which  situations  they 
apply  and  what  their  consequences  are,  at  the  point  of  their  definition.  Furthermore,  while  writing  such 
functions,  the  user  can  issue  queries  to  the  VeriML  type  checker  in  order  to  make  use  of  the  available  type 
information.  In  this  way,  they  will  learn  of  the  hypotheses  at  hand  and  the  goals  that  need  to  be  proved 
at  yet-unwritten  points  of  the  function.  This  extends  the  benefit  of  interactive  proof  development  offered 
by  traditional  proof  assistants  to  the  case  of  proof-producing  functions. 

Typed  proof  scripts  arise  naturally  by  composing  such  functions  together.  They  are  normal  VeriML 
expressions  whose  type  specifies  that  they  yield  a  proof  of  a  specific  proposition  upon  successful  eval¬ 
uation;  for  this  reason  we  also  refer  to  them  as  proof  expressions.  The  evolution  of  proof  state  in  these 
scripts  is  captured  explicitly  in  their  types.  Thus,  we  know  the  hypotheses  and  goals  that  their  sub-parts 
prove,  enabling  us  to  reuse  and  compose  proof  scripts.  Interactive  development  of  proof  scripts  is  offered 
by  leaving  parts  of  proof  scripts  unspecified,  and  querying  the  VeriML  type  checker.  The  returned  type 
information  corresponds  exactly  to  the  information  given  by  a  traditional  interactive  proof  assistant. 

An  important  point  is  that  despite  the  types  assigned  to  tactics  and  proof  scripts,  the  presence  of  side- 
effects  such  as  non-termination  means  that  their  evaluation  can  still  fail.  Thus,  proof  scripts  need  to  be 
evaluated  in  order  to  ensure  that  they  evaluate  successfully  to  a  proof  object.  Type  safety  ensures  that  if 
evaluation  is  indeed  successful,  the  resulting  proof  object  will  be  a  valid  proof,  proving  the  proposition 
that  is  claimed  from  the  type  system. 
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Figure  2.4:  Comparison  of  small-scale  automation  approach  between  current  proof  assistants  and  VeriML 

Small-scale  automation.  We  view  the  type  checker  as  a  ‘behind-the-scenes’  process  that  gives  helpful 
information  to  the  user  and  prevents  a  large  class  of  errors  when  writing  proofs  and  proof-producing 
functions.  This  mitigates  the  problems  (1),  (2),  (3)  identified  above  that  current  proof  assistants  have.  But 
what  about  support  for  small-scale  automation?  Our  main  intuition  is  to  view  small-scale  automation 
mechanisms  as  normal  proof-producing  functions,  with  two  extra  concerns  -  which  are  traditionally  mixed 
together.  The  first  concern  is  that  these  mechanisms  apply  ubiquitously,  transparently  to  the  user,  taking 
care  of  details  that  the  user  should  not  have  to  think  about.  The  second  concern  is  that  in  some  cases,  as  in 
the  case  of  the  conversion  rule  supported  in  Coq,  these  mechanisms  are  used  for  optimization  purposes: 
by  including  them  in  the  trusted  core  of  the  proof  assistant,  we  speed  up  proof  object  generation  and 
checking. 

With  respect  to  the  first  concern,  we  view  small-scale  automation  as  another  phase  of  checking,  similar 
to  typing,  as  presented  in  Figure  2.4.  Just  like  typing,  it  should  happen  ‘behind-the-scenes’  and  offer 
helpful  information  to  the  user:  when  we  allude  to  a  fact  that  holds  trivially,  small-scale  automation 
should  check  if  that  fact  indeed  holds  and  provide  sufficient  proof.  This  is  similar  to  a  second  phase  of 
type  checking,  save  for  the  fact  that  it  should  be  extensible.  This  checking  should  apply  both  in  the  case 
of  developing  a  proof  and  in  the  case  of  developing  a  proof-producing  function  -  otherwise  the  function 
could  fail  at  exactly  those  points  that  were  deemed  too  trivial  to  explicitly  prove.  The  user  should  be  able 
to  provide  their  own  small-scale  automation  procedures,  tailored  to  their  domain  of  interest.  This  view 
generalizes  the  notion  of  what  small-scale  automation  should  be  about  in  proof  assistants;  we  believe  it 
better  reflects  the  informal  practice  of  omitting  details. 

Based  on  this  idea,  we  can  say  that  the  main  distinction  between  small-scale  automation  and  large- 
scale  automation  is  only  a  matter  of  the  phase  when  they  are  evaluated.  Small-scale  automation  should 


21 


be  evaluated  during  a  phase  similar  to  type-checking,  so  that  we  know  its  results  at  the  definition  time 
of  a  proof  script  or  a  proof-producing  function.  Other  than  that,  both  should  be  implemented  through 
exactly  the  same  code.  We  introduce  such  a  phase  distinction  by  adding  a  static  evaluation  phase.  This 
phase  occurs  after  type  checking  but  before  normal  runtime  evaluation.  We  annotate  calls  to  the  small- 
scale  automation  mechanisms  to  happen  during  this  phase  through  a  simple  staging  construct.  Other  than 
this  annotation,  these  calls  are  entirely  normal  calls  to  ordinary  proof-producing  functions.  We  can  even 
hide  such  calls  from  the  user  by  employing  some  simple  syntactic  sugar.  Still  the  user  is  able  to  use  the 
same  annotations  for  new  automation  mechanisms  that  they  develop. 

The  second  concern  that  small-scale  automation  addresses,  at  least  in  the  case  of  the  conversion  rule, 
is  keeping  the  proof  object  size  tractable.  We  view  the  conversion  rule  as  a  trusted  procedure  that  is 
embedded  within  the  proof  checker  of  the  logic,  one  that  decides  equivalences  as  mentioned.  The  fact 
that  we  trust  its  implementation  is  exactly  why  we  can  omit  the  proof  of  those  equivalences  from  the 
proof  objects.  We  can  therefore  say  that  the  conversion  rule  is  a  special  proof-producing  procedure  that 
does  not  produce  a  proof  -  because  we  trust  that  such  a  proof  exists. 

Consider  now  the  implementation  of  the  conversion  rule  as  a  function  in  VeriML.  We  can  ascribe  a 
strong  type  to  this  function,  where  we  specify  that  if  this  function  says  that  two  propositions  are  equiv¬ 
alent,  it  should  in  fact  return  a  proof  object  of  that  equivalence.  Because  of  the  type  safety  of  VeriML, 
we  know  that  if  a  call  to  this  function  evaluates  successfully,  such  a  proof  object  will  indeed  be  returned. 
But  we  can  take  this  one  step  further:  the  proof  object  does  not  even  need  to  be  generated  yet  is  guaran¬ 
teed  to  exist  because  of  type  safety.  We  say  that  VeriML  can  be  evaluated  under  proof-erasure  semantics  to 
formally  describe  this  property.  Therefore,  we  can  choose  to  evaluate  the  conversion  rule  under  proof- 
erasure,  resulting  in  the  same  space  savings  as  in  the  traditional  approach.  Still  the  same  semantics  can  be 
used  for  further  extensions  for  better  space  and  time  savings.  By  this  account,  it  becomes  apparent  that 
the  conversion  rule  can  be  removed  from  the  trusted  core  of  the  system  and  from  the  core  logical  theory 
as  shown  in  Figure  2.4,  without  losing  any  of  the  benefits  that  the  tight  integration  provides. 

Overall,  we  can  view  VeriML  as  an  evolution  of  the  tradition  of  the  LCF  family,  informed  by  the  fea¬ 
tures  of  the  current  state-of-the-art  proof  assistants.  In  the  LCF  family,  both  the  logic  and  the  logic- 
manipulating  functions  are  implemented  within  the  same  language,  ML.  In  VeriML,  the  implementation 
of  the  logic  becomes  part  of  the  base  computational  language.  Logic-manipulating  functions  can  thus 
be  given  types  that  include  the  information  gathered  from  the  type  system  of  the  logic,  in  order  to  re¬ 
flect  the  properties  of  the  logical  terms  involved.  This  information  enables  interactive  development  of 
proof  scripts  and  proof-producing  functions  and  also  leads  to  a  truly  extensible  approach  to  small-scale 
automation,  generalizing  the  benefits  offered  by  current  proof  assistants  in  both  cases. 

2.3  Brief  overview  of  the  language 

In  this  section,  we  will  give  a  brief  informal  overview  of  the  main  features  of  VeriML.  We  will  present 
them  mostly  through  the  development  of  a  procedure  that  proves  propositional  tautologies  automatically. 
We  assume  some  familiarity  with  functional  programming  languages  in  the  style  of  ML  or  Haskell. 
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A  simple  propositional  logic 

In  order  to  present  the  programming  constructs  available  in  VeriML  in  detail,  we  will  first  need  to  be  more 
concrete  with  respect  to  what  our  logic  actually  is  -  what  propositions  and  proofs  we  will  manipulate  and 
produce.  For  the  purposes  of  our  discussion,  we  will  choose  a  very  simple  propositional  logic  which  we 
briefly  present  here.  Through  this  logic,  we  can  state  and  prove  simple  arguments  of  the  form: 

1 .  If  it  is  raining  and  I  want  to  go  outside,  I  need  to  get  my  umbrella. 

2.  It  is  raining. 

3.  I  want  to  go  outside. 

4.  Therefore,  I  need  to  get  my  umbrella. 

This  logic  consists  of  two  classes  of  terms:  propositions  and  proofs.  Propositions  are  either  atomic 
propositions  (e.g.  “it  is  raining”),  denoted  as  A,  which  state  a  fact  and  are  not  further  analyzable,  or  are 
combinations  of  other  propositions  through  logical  connectives:  conjunction,  denoted  as  A;  disjunction, 
denoted  as  V;  and  implication,  denoted  as  D.  We  use  capital  letters  P,  Q,R  to  refer  to  propositions.  The 
propositions  of  our  logic  are  formed  through  the  following  grammar: 

P  ::=  Pi  A  P2  |  Pj  V  P2  |  Pi  D  P2  \  A 

Proofs  are  evidence  that  certain  propositions  are  valid.  We  will  give  precise  rules  for  a  specific  form 
that  such  evidence  might  take;  we  will  therefore  describe  a  formal  proof  system.  Every  rule  has  some 
premises  and  one  consequence.  The  premises  describe  what  proofs  are  required.  By  filling  in  a  proof 
for  each  required  premise,  we  get  a  proof  for  the  consequence.  We  write  rules  in  a  vertical  style,  where 
premises  are  described  in  the  top  and  the  consequence  in  the  bottom,  divided  by  an  horizontal  line.  Proofs 
therefore  have  a  bottom-up  tree-like  structure,  with  the  final  consequence  as  the  root  of  the  tree  at  the  very 
bottom  of  the  proof.  Proofs  can  also  make  use  of  hypotheses,  which  are  the  set  of  leaves  of  this  tree.  A 
hypothesis  corresponds  to  an  assumption  that  a  proof  of  a  certain  proposition  exists. 

Every  connective  is  associated  with  two  sets  of  logical  rules:  a  set  of  introduction  rules,  which  describe 
how  we  can  form  a  proof  of  a  proposition  involving  that  connective,  and  a  set  of  elimination  rules,  which 
describe  what  further  proofs  we  can  construct  when  we  have  a  proof  about  that  connective  at  hand.  The 
logical  rules  for  conjuction  are  the  simplest  ones: 


P  Q  PAQ  PAQ 

- AlNTRO  - AELIMl  - AELIM2 

PAQ  P  Q 

The  content  of  these  rules  is  as  follows.  The  introduction  rules  says  that  to  form  a  proof  of  a  conjunction, 
we  need  two  proofs  as  premises,  whose  consequences  are  the  two  propositions  involved.  Inversely,  the 
elimination  rules  say  that  out  of  a  proof  of  a  conjunction,  we  can  extract  a  proof  of  either  proposition, 
using  the  corresponding  rule. 
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p 


Q  PdQ  P 

- dIntro  - dElim 

PdQ  Q 

Introduction  of  implication  is  a  little  bit  more  complicated:  it  is  proved  through  a  proof  of  the  proposition 
Q,  where  we  can  make  use  of  an  extra  hypothesis  for  P  -  that  is,  an  assumption  that  we  have  a  proof  of 
proposition  P.  This  is  what  the  notation  in  the  introduction  rule  stands  for.  Elimination  of  implication 
corresponds  to  the  well-known  modus  ponens  reasoning  principle. 

The  rules  about  disjunction  follow.  The  introduction  rules  are  straightforward;  the  elimination  rule 
says  that  given  a  proof  of  P  V  Q,  if  we  can  prove  a  third  proposition  R  starting  with  either  a  proof  of  P  or 
a  proof  of  Q  as  hypotheses,  then  we  have  a  proof  of  R  without  any  extra  hypotheses. 

—  ~Q 


P  Q  R  R  P  V  Q 

- VlNTROl  - VINTR02  - VELIM 

P  V  Q  P  V  Q  R 

Based  on  these  rules,  we  can  form  simple  proofs  of  propositional  tautologies.  For  example,  we  can 
prove  that  P  D  (P  A  P)  as  follows. 

P  P 
PAP 

PD(PAP) 


Logical  terms  as  data 


In  VeriML,  logical  terms  such  as  propositions  and  proofs  are  a  type  of  data  -  similar  to  integers,  strings 
and  lists.  We  therefore  have  constant  expressions  in  order  to  introduce  them,  just  as  we  have  constant 
expressions  such  as  1,  2,  and  "hello  world"  for  normal  data  types.  We  use  (P)  as  the  constant  expression 
for  a  proposition  P,  thus  differentiating  the  computational  expression  from  the  normal  logical  term. 

Unlike  normal  types  like  integers,  the  type  of  these  constant  expressions  is  potentially  different  based 
on  the  logical  term  we  introduce.  In  the  case  of  proofs,  we  assign  its  consequence  -the  proposition  that  it 
proves-  as  its  type.  Therefore  logical  terms  have  types  that  involve  further  logical  terms.  We  denote  the 
type  corresponding  to  the  logical  term  P  as  (P).  Therefore,  the  constant  expression  corresponding  to  the 
proof  given  in  the  previous  section  will  be  written  and  typed  as  follows.  Note  that  we  use  a  shaded  box  for 
types;  this  is  meant  as  an  annotation  which  users  of  the  language  do  not  have  to  write,  but  is  determined 
through  the  type  checker. 


/  PAP  \ 
\PdPAP/ 


:  (PdPAP) 
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Propositions  get  assigned  a  special  logical  term,  the  sort  Prop.  Other  than  this,  they  should  be  perceived 
as  normal  data.  For  example,  we  can  form  a  list  of  propositions,  as  follows: 

[(P  D  Q) ;  (P  A  Q  V  R)]  :  (Prop)  list 

Dependent  functions  and  tuples 

Let  us  now  consider  our  motivating  example:  writing  a  procedure  that  automatically  proves  propositional 
tautologies  -  propositions  that  are  always  valid,  without  any  hypotheses.  What  should  the  type  of  this 
procedure  be?  We  want  to  specify  the  fact  that  it  accepts  a  proposition  and  produces  a  proof  of  that 
proposition.  The  type  of  the  result  is  thus  dependent  on  the  input  of  the  function.  We  introduce  names 
in  the  types  so  as  to  be  able  to  track  such  dependencies,  allowing  us  to  give  the  following  type  to  our 
tautology  prover: 

tautology  :  (P  :  Prop)  —*■  (P) 

Similarly,  we  can  have  dependent  tuples  -  tuples  where  the  type  of  the  second  component  might  depend 
on  the  first  component.  In  this  way  we  can  form  a  pair  of  a  proposition  together  with  a  proof  for  this 
proposition  and  use  such  pairs  in  order  to  create  lists  of  proofs: 


(pdp. 


—) 

PDP/ 


P  DP  A  P, 


P  P  , 

PAP 

PdPAP 


:  (P:Prop,X:P)  list 


Pattern  matching  on  terms 

Our  automated  prover  is  supposed  to  prove  a  proposition  -  but  in  order  to  do  that,  it  needs  to  know  what 
that  proposition  actually  is.  In  order  to  be  able  to  write  such  functions,  VeriML  includes  a  construct  for 
pattern  matching  over  logical  terms.  Let  us  consider  the  following  sketch  of  our  tautology  prover: 


tautology  :  (P  :  Prop)  — *■  ( P ) 

tautology  P  =  match  P  with 

QAR  >•  letX  =  tautology  (Q)  in 
let  Y  =  tautology  (R)  in 

|  Q  VP?  ••• 

We  pattern  match  on  the  input  proposition  P  in  order  to  see  its  topmost  connective.  In  the  conjunc¬ 
tion  case,  we  recursively  try  to  find  a  proof  for  the  two  propositions  involved.  In  the  disjunction  case,  we 
need  to  try  finding  a  proof  for  either  of  them.  Our  prover  will  not  always  be  successful  in  finding  a  proof, 
since  not  all  propositions  are  provable.  Therefore  we  can  refine  the  type  of  our  prover  so  that  it  optionally 
returns  a  proof  -  through  the  use  of  the  familiar  ML  option  type.  The  new  sketch  looks  as  follows,  where 
we  use  monadic  syntax  for  presentation  purposes: 
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tautology  :  (P  :  Prop)  —*  (P)  option 

tautology  P  =  match  P  with 

QAR  ►  do  X  <—  tautology  (Q)  ; 

Y  <—  tautology  ( R }  ; 
return  •  •  -j 

|  Q  VP  (do  X  <—  tautology  (  Q  }  ; 

return  •  •  -2)  || 

(do  F  <—  tautology  (P)  ; 
return  •  •  -3) 

What  do  the  variables  X  and  Y  stand  for?  The  evaluation  of  the  recursive  calls  such  as  tautology  Q 
will  result  in  a  proof  which  will  have  Q  as  the  consequence  and  an  arbitrary  set  of  hypotheses.  Thus  X 
is  a  variable  that  stands  for  a  proof  of  Q;  it  will  be  replaced  by  an  actual  proof  once  the  call  to  tautology 

is  evaluated6.  Though  we  can  write  the  type  of  X  as  (Q),  another  way  to  write  it  is  X  :  Q  ,  reflecting 
the  fact  that  X  can  be  viewed  as  a  proof  of  Q.  The  above  description  of  the  nature  of  X  is  quite  similar 
to  a  hypotheses  of  Q  used  inside  a  proof.  Yet  there  is  a  difference:  hypotheses  stand  for  closed  proofs,  that 
is,  proofs  without  additional  hypotheses;  whereas  X  stands  for  an  open  proof,  which  can  have  arbitrary 
additional  hypotheses.  This  is  why  we  refer  to  X  as  a  meta-variable.  We  can  use  such  meta-variables  inside 
proofs,  in  which  case  we  can  perceive  them  as  holes  that  are  later  filled  in  with  the  actual  proofs. 

Let  us  now  focus  on  the  missing  parts.  By  issuing  a  query  to  the  VeriML  typechecker  for  this  incom¬ 
plete  program,  we  will  get  back  the  following  information: 


P,  Q,P:  (Prop) 


Y:  (Q) 

P,Q,R:  (Prop) 

P,Q,R  :  (Prop) 

F:  (R) 

X  :  (Q) 

F:  (R) 

■  ■  v :  (QAR) 

"  '2  •  (Qvtf) 

-3=  (Qvtf) 

The  typechecker  informs  us  of  the  proofs  that  we  have  at  hand  in  each  case  and  of  the  type  of  the 
VeriML  expression  that  we  need  to  fill  in.  When  we  fill  them  in,  the  typechecker  will  also  make  sure  that 
the  proofs  indeed  follow  the  rules  of  the  logic  and  have  the  right  consequences,  based  on  their  required 
type.  In  this  way  many  errors  can  be  caught  early.  The  rich  information  contained  in  these  types  and 
the  ability  to  use  them  to  check  the  proofs  enclosed  in  functions  such  as  tautology  is  one  of  the  main 
departures  of  VeriML  compared  to  traditional  proof  assistants,  where  all  the  proofs  inside  such  functions 
show  up  as  having  the  same  type. 

6.  The  astute  reader  will  notice  that  we  are  being  a  bit  imprecise  here  in  the  interest  of  presentation.  More  accurately,  the  call 
to  tautology  will  result  in  a  constant  expression  enclosing  a  proof  with  Q  as  a  consequence,  and  an  arbitrary  set  of  hypotheses. 
As  written  in  the  code  example,  A  is  a  variable  that  stands  for  such  a  constant.  Instead,  we  should  write  ( X  )  <—  tautology  Q, 
making  the  fact  that  X  refers  to  the  proof  enclosed  within  the  returned  constant  apparent. 
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We  note  that  the  typechecker  has  taken  into  account  the  information  for  each  particular  branch  in 
order  to  tell  what  proof  needs  to  be  filled  in.  We  thus  say  that  pattern  matching  is  dependent.  Based  on 
the  provided  information,  it  is  easy  to  fill  in  the  missing  expressions: 


'X:  Q 


Y :  R 


< X :  Q 


Y:  R 


1  — 


QVR 


2  — 


QVR 


3  — 


QVR 


If  we  made  a  typo  when  filling  in  •  •  q,  such  as: 


the  type  checker  would  be  able  to  inform  us  of  the  error  and  decline  the  definition  of  tautology. 


Contextual  terms 

The  previous  sketch  of  the  automated  prover  still  lacks  two  things:  support  for  logical  implication  as 
well  as  (perhaps  more  importantly)  a  base  case.  In  fact,  both  of  these  are  impossible  to  implement  in  a 
meaningful  way  based  on  what  we  have  presented  so  far,  because  of  a  detail  that  we  have  been  glossing 
over:  hypotheses  contexts. 

Consider  the  implication  introduction  rule  given  above. 

P 


-  DlNTRO 

PdQ 

The  premise  of  the  rule  calls  for  a  proof  of  Q  under  the  assumption  that  P  holds.  So  far,  we  have  been 
characterizing  proofs  solely  based  on  the  proposition  that  they  prove,  so  we  cannot  capture  the  require¬ 
ment  for  an  extra  assumption.  Essentially,  we  have  been  identifying  all  proofs  of  the  same  proposition 
that  depend  on  different  hypotheses.  This  is  clearly  inadequate:  consider  the  difference  between  a  proof 
of  P  with  no  hypotheses  and  a  proof  of  P  with  a  hypothesis  of  P. 

In  order  to  fix  this  issue,  we  will  introduce  a  context  of  hypotheses  $.  We  can  reformulate  our  logical 
rules  so  that  they  correspond  to  hypothetical  judgements ,  where  the  dependence  on  hypotheses  is  clearly 
recorded.  We  write  $  h  P  for  a  proof  where  the  context  of  hypotheses  is  $  and  the  consequence  is  P.  The 
new  formulation  of  the  implication  rules  is  as  follows;  the  other  rules  are  re-formulated  similarly. 

$,  PbQ  $b  PdQ  $b  P 

- DlNTRO  -  dElim 

$bQ  $bQ 

Furthermore,  we  will  make  two  changes  to  the  computational  constructs  we  have  seen.  First,  the 
types  of  the  proofs  will  not  simply  be  their  consequence,  but  will  record  the  hypotheses  context  as  well, 
reflecting  the  new  judgement  form  $  h  P.  We  can  also  say  that  the  type  of  proofs  are  now  contextual 
terms  instead  of  simple  logical  terms  -  that  is,  they  are  logical  terms  with  their  context  (the  hypothesis 
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context  they  depend  on)  explicitly  recorded.  Second,  we  will  add  dependent  functions  over  contexts  which 
are  similar  to  the  dependent  functions  over  logical  terms  that  we  have  seen  so  far.  We  will  use  this  latter 
feature  in  order  to  write  code  that  works  under  any  context  <£,  just  like  our  tautology  proven 
Based  on  these,  we  give  the  new  sketch  of  our  prover  with  the  implication  case  added: 

tautology  : 

tautology  = 

QAR  >— >  do  X  <—  tautology  $  (Q)  ; 

Y  <—  tautology  $  (R)  ; 
return  •  •  •, 

|  Q  V  R  >->•  (do  X  <—  tautology  $  (  Q  )  ; 
return  •  •  -2)  || 

(do  Y  *—  tautology  $  (R)  ; 
return  •  •  -3) 

|  Qd  R  >->•  do  X  <—  tautology  ($,  Q)  ( R  )  ; 

/X:  $,  QbA 

return  (  - 

\  $FQdA 


(<1> :  context )  — *  (P  :  Prop)  —»•(<&  h  P)  option 
match  P  with 


A  similar  problem  becomes  apparent  if  we  inspect  the  propositions  that  we  have  been  constructing 
in  VeriML  under  closer  scrutiny:  we  have  been  using  the  names  P,  Q,  etc.  for  atomic  propositions  - 
but  where  do  those  names  come  from?  The  answer  is  that  those  come  from  a  variables  context,  similar 
to  how  proofs  for  assumptions  come  from  a  hypotheses  context.  In  the  logic  that  VeriML  is  based  on, 
these  contexts  are  mixed  together.  In  order  to  be  able  to  precisely  track  the  contexts  that  propositions  and 
proofs  depend  on,  all  logical  terms  in  VeriML  are  contextual  terms,  as  are  their  types. 

Pattern  matching  on  contexts 

The  prover  described  above  is  still  incomplete,  since  it  has  no  base  case  for  atomic  propositions.  For  such 
propositions,  the  only  thing  that  we  can  do  is  to  search  our  hypotheses  to  see  if  we  already  possess  a  proof 
for  them.  Now  that  the  hypotheses  context  is  explicitly  represented,  we  can  view  it  as  data  that  we  can 
look  into,  just  as  we  did  for  logical  terms.  VeriML  therefore  has  a  further  pattern  matching  construct  for 
matching  over  contexts. 

We  will  write  a  function  findHyp  that  tries  to  find  whether  a  specific  hypothesis  exists  in  the  current 
context,  by  looking  through  the  context  for  an  exact  match.  Note  the  use  of  the  variable  H  in  the  first 
inner  branch:  the  pattern  will  match  if  the  current  element  of  the  context  is  a  hypothesis  which  matches 
the  desired  proposition  H  exactly.  Contrast  this  with  the  last  branch,  where  we  use  a  wildcard  pattern  to 
match  any  other  hypothesis. 
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findHyp  :  ($  :  context)  — *■  {H  :  Prop)  —>•(<&  h  Pf)  option 

findHyp  4>F/  =  match  $  with 

0  s  None 

|  ($/,  PP)  s  match  H'  with 

H  s  return  (  - 

|_  -►  findHyp (H) 

Furthermore,  we  add  a  case  at  the  end  of  our  prover  in  order  to  handle  atomic  propositions  using  this 
function. 

tautology  4>P  =  match  P  with 

|  P  s  findHyp  $  (  P  } 

With  this,  the  first  working  version  of  our  prover  is  complete.  We  can  now  write  a  simple  proof  script 
in  order  to  prove  the  tautology  P  D  P  A  P,  as  follows: 

lettautol  :  (FPdPAP)  =  tautology  0  (P  D  P  AP) 

This  will  return  the  proof  object  for  the  proposition  we  gave  earlier.  Through  type  inference  the  VeriML 
type  checker  can  tell  what  the  arguments  to  tautology  should  be,  so  users  would  leave  them  as  implicit 
arguments  in  an  actual  proof  script. 

It  is  easy  to  modify  our  tautology  prover  to  be  more  open-ended,  by  allowing  the  use  of  functions 
other  than  findHyp  to  handle  the  base  cases.  We  can  do  this  thanks  to  the  support  for  higher-order  func¬ 
tions  of  the  ML  core  of  our  language.  Consider  the  following  auto  function.  Most  of  the  branches  are 
identical  to  tautology,  save  for  the  base  case  which  makes  a  call  to  another  proving  function,  supplied  as 
an  input  argument. 

auto  :  :  context)  — *  ( P  :  Prop )  — >  ($  h  P)  option  j 

— *■  ($  :  context )  — *  (P  :  Prop )  — *■  ($  h  P)  option 
auto  baseprover  $  P  =  match  P  with 

•  •  •  (same  as  tautology)  ■  ■  ■ 

|  P  is  baseprover  $  ( P  } 

We  can  now  use  different  base  provers  in  combination  with  auto.  For  example,  we  can  combine 
auto  with  an  arithmetic  theorem  prover:  a  function  arith  that  can  handle  goals  of  the  form  $  h  P  where 
all  hypothesis  in  $  and  the  desired  consequence  in  P  are  atomic  propositions  involving  arithmetic.  In 
this  way,  the  arithmetic  prover  is  extended  into  a  prover  that  can  handle  propositions  involving  both 
arithmetic  and  logical  connectives  -  with  the  logical  reasoning  handled  by  auto.  By  combining  functions 
in  this  way,  we  construct  proof  expressions  that  compute  proofs  for  the  desired  propositions. 

Mixing  imperative  features 

Our  prover  so  far  has  been  purely  functional.  Even  though  we  are  manipulating  terms  such  as  proposi¬ 
tions  and  contexts,  we  still  have  access  to  the  full  universe  of  data  structures  that  exist  in  a  normal  ML 


29 


implementation  -  such  as  integers,  algebraic  data  types  (e.g.  lists  that  we  saw  above),  mutable  references 
and  arrays.  We  can  include  logical  terms  as  parts  of  such  data  structures  without  any  special  provision. 
One  simple  example  would  be  a  memoized  version  of  our  prover,  which  keeps  a  cache  of  the  propositions 
that  it  has  already  proved,  along  with  their  proofs. 

tautologyCache  :  ($  :  context,  P  :  Prop,  $  bP)  option  array 

memoizedTautology  :  ($  :  context )  — >  ( P  :  Prop )  — y  ($  b  P)  option 

memoizedTautology  $  P  = 

let  entry  =  hash  ($,P)  in 
match  tautologyCache[entry]  with 
Some  (  }  >->•  Some(X) 

|  _  ►->  do  X  <—  tautology  $  (P)  ; 

tautologyCache[entry]  :=  (<I>,P,X)  ; 
return  ( X  ) 


Staging 

Let  us  now  assume  that  we  have  developed  our  prover  further,  to  be  able  to  prove  more  tautologies 
compared  to  the  rudimentary  prover  given  above.  Suppose  we  want  to  write  a  function  that  performs 
a  certain  simplification  on  a  given  proposition  and  returns  a  proof  that  the  transformed  proposition  is 
equivalent  to  the  original  one.  It  will  have  the  following  type: 

simplify  :  (P  :  Prop )  — *■  (Q  :  Prop,  0hPuQAQDP) 

Consider  a  simple  case  of  this  function: 

simplify  P  =  match  P  with 

QARdO  -►  (Qd  RD  O,--} 

If  we  query  the  VeriML  typechecker  about  the  type  of  the  missing  part,  we  will  learn  the  proposition 
that  we  need  to  prove: 

P,Q,R,0  :  {Prop) 

■  ■  ■ :  ((Q  AR  D  O)  D  (Q  D  R  D  O))  A((Q  D  R  D  O)  D  (Q  AR  D  O)) 

How  do  we  fill  in  this  missing  part?  One  option  is  to  replace  it  by  a  complete  proof.  But  we  already 
have  a  tautology  prover  that  is  able  to  handle  this  proposition,  so  we  would  rather  avoid  the  manual  effort. 

The  second  option  would  be  to  replace  this  part  with  a  call  to  the  tautology  prover:  •  •  •  =  tautology _ , 

where  we  have  left  both  arguments  implicit  as  they  can  be  easily  inferred  from  the  typing  context.  Still, 
this  would  mean  that  every  time  the  tactic  is  called  and  that  branch  is  reached,  the  same  call  to  the  prover 
would  need  to  be  evaluated.  Furthermore,  we  would  not  know  whether  the  prover  was  indeed  successful 
in  proving  this  proposition  until  we  reach  that  branch  -  which  might  never  happen  if  it  is  a  branch  not 
exercised  by  a  test  case!  The  third  option  is  to  separate  this  proposition  into  a  lemma,  similar  to  what  we 
did  for  tautol,  and  prove  it  prior  to  writing  the  simplify  function.  This  option  is  undesirable  too,  because 


30 


the  statement  of  the  lemma  itself  is  not  interesting;  furthermore  it  is  much  more  verbose  than  the  call  to 
the  prover  itself.  Having  to  separate  such  uninteresting  proof  obligations  generated  by  functions  such  as 
simplify  as  lemmas  would  soon  become  tedious. 

In  VeriML  we  can  solve  this  issue  through  the  use  of  staging.  We  can  annotate  expressions  so  that 
they  are  staged  -  they  are  evaluated  during  a  phase  of  evaluation  that  happens  after  typing  but  before 
runtime.  These  expressions  can  be  inside  functions  as  well,  yet  they  are  still  evaluated  at  the  time  that 
these  functions  are  defined.  Through  this  approach,  we  get  the  benefits  of  the  separation  into  lemmas 
approach  but  with  the  conciseness  of  the  direct  call  to  the  prover.  The  example  code  would  look  as 
follows.  We  use  brackets  as  the  staging  annotation  for  expressions. 

simplify  P  =  match  P  with 

Q  ARd  O  (Qd  RD  O,  {tautology _ }} 

After  type  checking,  this  expression  is  made  equivalent  to  the  following,  where  the  missing  arguments 
are  filled  in  based  on  the  typing  information. 

simplify  P  =  match  P  with 

QARdO  !-*■  (QdRdO,  {tautology  0  S}} 

where  S  =  ((Q  AR  D  O)  D  (Q  D  R  D  O))  A  ((Q  D  R  D  O)  D  (Q  AR  D  O)) 

After  the  static  evaluation  phase,  the  staged  expression  gets  replaced  by  the  proof  that  is  returned  by 
the  tautology  prover. 

simplify  P  =  match  P  with 

QARdO  -►  (QdAdO,A) 

where  A  = - 

0  h  5 

where  S  =  ((Q  A  R  D  O)  D  (Q  D  R  D  O))  A  ((Q  D  R  D  O)  D  (Q  A  R  D  O)) 

Proof  erasure 

The  last  feature  of  VeriML  that  we  will  consider  is  proof  erasure.  Based  on  the  type  safety  of  the  language, 
we  know  that  expressions  of  a  certain  type  will  indeed  evaluate  to  values  of  the  same  type,  if  successful. 
For  example,  consider  an  expression  that  uses  functions  such  as  tautology  in  order  to  prove  a  proposition 
P:  if  the  expression  does  evaluate  to  a  result  (instead  of  diverging  or  throwing  an  exception),  that  result 
will  be  a  valid  proof  of  P. 

We  have  said  that  we  are  able  to  pattern  match  on  logical  terms  such  as  propositions  and  proofs. 
If  we  relax  this  so  that  we  cannot  pattern  match  on  proof  terms,  type  safety  can  give  us  the  further 
property  of  proof-erasure:  if  we  delete  all  proofs  from  our  VeriML  expressions  and  proceed  to  evaluate 
these  expressions  normally,  their  runtime  behavior  is  exactly  the  same  as  before  the  deletion  -  other  than 
the  space  savings  of  not  having  to  realize  the  proofs  as  data  in  the  computer  memory.  Therefore,  even 
if  we  do  not  generate  these  proofs,  valid  proof  objects  are  still  guaranteed  to  exist.  Relaxing  the  pattern 
matching  construct  as  such  is  not  a  serious  limitation,  as  we  are  not  interested  in  the  particular  structure 
of  a  proof  but  only  on  its  existence. 
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For  purposes  of  our  discussion,  we  will  show  what  the  proof-erased  version  of  the  prover  we  have 
written  above  would  look  like. 

tautology  :  ($  :  context)  — ►  (P  :  Prop)  — *■  unit  option 

tautology  $  P  =  match  P  with 

QAR  do  tautology  $  Q  ; 

tautology  $  R  ; 
return  () 

|Q  Vi?  i->  (do  tautology  $  Q  ; 

return  ())  || 

(do  tautology  $  i?  ; 
return  ()) 

|  Q  D  i?  >->•  do  tautology  ($,  Q)  R  ; 
return  () 

This  code  looks  very  similar  to  what  we  would  write  in  a  normal  ML  function  that  did  not  need  to 
produce  proofs.  This  equivalence  is  especially  evident  if  we  keep  in  mind  that  unit  option  is  essentially  the 
boolean  type,  monadic  composition  corresponds  to  boolean  AND,  monadic  return  to  boolean  true  and 
the  1 1  operation  to  boolean  OR. 

The  space  savings  associated  with  proof  erasure  are  considerable,  especially  in  the  case  of  functions 
that  are  used  ubiquitously  in  order  to  produce  proofs,  such  as  the  small-scale  automation  mechanisms  that 
we  mentioned  earlier  in  this  chapter.  Still,  full  proof  erasure  means  that  we  have  to  completely  trust 
the  VeriML  implementation.  Instead  we  will  use  proof  erasure  selectively,  e.g.  in  order  to  evaluate  the 
functions  comprising  the  conversion  rule,  enlarging  the  trusted  base  only  by  the  proof-erased  versions 
of  those  functions.  Yet  a  receiver  of  a  VeriML  proof  can  choose  to  re-evaluate  these  functions  without 
proof  erasure  and  get  complete  proofs  without  missing  parts.  Therefore  the  trusted  base  of  our  system 
is  not  decided  at  the  design  time  of  the  logic  we  are  going  to  use,  but  at  the  sites  of  the  receivers  of  the 
proofs.  This  allows  a  wide  range  of  possibilities  in  choosing  between  the  level  of  rigor  required  and  the 
cost  associated  with  proof  checking,  and  is  a  significant  advancement  from  the  traditional  way  of  handling 
proofs  as  certificates  sent  to  a  third  party. 

Last,  we  would  like  to  briefly  comment  on  the  fact  that  the  combination  of  proof  erasure  with  the 
staging  annotation  is  very  powerful,  as  it  allows  us  to  extend  the  notion  of  what  constitutes  a  valid  proof. 
Take  the  following  sketch  of  a  proof  as  an  example: 


(%+y)2>0  {arith _ }: 

x2  +  2 xy  + 

In  this  proof,  we  use  the  automated  arithmetic  prover  arith  to  validate  a  simple  algebraic  identity.  By  using 
proof  erasure  for  this  call,  no  proof  object  for  this  identity  is  ever  generated  -  yet  we  are  still  guaranteed 
that  a  proof  that  uses  only  the  initial  logical  rules  (plus  axioms  of  arithmetic)  exists.  Furthermore,  this 
identity  is  validated  statically:  if  we  use  the  above  proof  inside  a  function  such  as  tautology  to  fill  in 
the  proof  obligations  (as  we  did  for  •  •  •,  earlier),  we  will  still  know  that  the  whole  proof  is  valid  at  the 
time  that  the  function  is  defined.  This  is  due  to  staging  the  call  to  the  arith  function.  This  process 


(x  +  y)2  =  x2  +  2  xy  +  y2 
y2  >  0 
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roughly  corresponds  to  extending  the  available  logical  rules  with  calls  to  proof-producing  functions;  yet 
we  maintain  the  property  that  we  can  statically  validate  these  “extended”  proofs.  The  fact  that  no  evidence 
needs  to  be  produced,  means  that  we  can  effectively  hide  these  trivial  details  -  both  in  terms  of  user  effort 
required,  and  of  the  cost  of  validating  them. 

Yet  the  automation  functions  handling  these  trivial  details  are  developed  in  VeriML,  which  means  that 
we  can  develop  better  versions  of  them  in  the  same  language  to  handle  further  details  or  further  domains. 
Thus  our  approach  to  small-scale  automation  departs  from  the  traditional  approach  of  hardcoding  fixed 
small-scale  automation  mechanisms  in  the  core  implementation  of  the  proof  assistant;  it  enables  instead 
layered  development  of  increasingly  more  sophisticated  small-scale  automation,  in  a  manner  resembling 
the  informal  practice  of  acquiring  further  intuition. 
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Chapter  3 

The  logic  AHOL:  Basic  framework 


In  this  chapter  we  will  present  the  details  of  the  aHOL  logic  that  VeriML  uses. 

3.1  The  base  /IHOL  logic 

The  logic  that  we  will  use  is  a  simple  type-theoretic  higher-order  logic  with  explicit  proof  objects.  This 
logic  was  first  introduced  in  Barendregt  and  Geuvers  [1999]  and  can  be  seen  as  a  shared  logical  core 
between  CIC  [Coquand  and  Huet,  1988,  Bertot  et  al.,  2004]  and  the  HOL  family  of  logics  as  used  in  proof 
assistants  such  as  HOL4  [Slind  and  Norrish,  2008],  HOL-Light  [Harrison,  1996]  and  Isabelle/HOL 
[Nipkow  et  al.,  2002],  It  is  a  constructive  logic  yet  admits  classical  axioms. 

The  logic  is  composed  of  the  following  classes: 

-  The  objects  of  the  domain  of  discourse,  denoted  d:  these  are  the  objects  that  the  logic  reasons 
about,  such  as  natural  numbers,  lists  and  functions  between  such  objects. 

-  The  propositions,  denoted  as  P :  these  are  the  statements  of  the  logic.  As  this  is  a  higher-order  logic, 
propositions  themselves  are  objects  of  the  domain  of  discourse  d,  having  a  special  Prop  type.  We 
use  P  instead  of  d  when  it  is  clear  from  the  context  that  a  domain  object  is  a  proposition. 

-  The  kinds,  denoted  JC:  these  are  the  types  that  classify  the  objects  of  the  domain  of  discourse, 
including  the  Prop  type  for  propositions. 

-  The  sorts,  denoted  s ,  which  are  the  classifiers  of  kinds. 

-  The  proof  objects,  denoted  n,  which  correspond  to  a  linear  representation  of  valid  derivations  of 
propositions. 

-  The  variables  context,  denoted  T,  which  is  a  list  of  variables  along  with  their  type. 

-  The  signature,  denoted  S,  which  is  a  list  of  axioms,  each  one  corresponding  to  a  constant  and  its 
type. 

The  syntax  of  these  classes  is  given  in  Figure  3.1,  while  the  typing  judgements  of  the  logic  are  given  in 
Figures  3.2  and  3.3.  We  will  now  comment  on  the  term  formers  and  their  associated  typing  rules. 

The  proposition  Pj  — >  P2  denotes  logical  implication  whereas  the  kind  former  /C,  — >  /C2  is  inhab¬ 
ited  by  total  functions  between  domain  objects.  Both  use  the  standard  forms  of  lambda  abstraction  and 
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5 


(sorts) 

(kinds) 

(dom.obj.  and  prop.) 
(proof  objects) 
(variable  contexts) 
(constant  signature) 


K 

d,P 

71 

$ 

E 


=  Type  |  Type 

=  ProP  \ck\ICi^IC2 

=  P1  —*■  P2  |  Vx  :  JC.P  |  Ax  :  JC.d  \  dx  d2  \  x  \  cj 
=  Ax  :  P.n  |  7i  n  |  Ax  :  JC.n  \  n  d\x\cn 
=  •  |  $,  x  :  Type  |  3>,  x  :  1C  |  $,  x  :  P 
=  •  |  E,  C/c  :  Type  |  E,  cd  :  K  |  E,  cn  :  P 


Figure  3.1:  The  base  syntax  of  the  logic  dHOL 

function  application  as  their  introduction  and  elimination  rules.  In  the  case  of  the  proposition  Pl  — >  P2, 
the  typing  rules  for  the  proof  objects  Ax  :  P1.n  and  n1  n7  correspond  exactly  to  the  introduction  and 
elimination  rules  for  logical  implication  as  we  gave  them  in  Section  2.3;  the  proof  objects  are  simply  a 
way  to  record  the  derivation  as  a  term  instead  of  a  tree.  The  proposition  Vx  :  K..P  denotes  universal 
quantification.  As  K,  includes  a  domain  former  for  propositions  and  functions  yielding  propositions,  we 
can  quantify  over  propositions  and  predicates.  This  is  why  dHOL  is  a  higher-order  logic  -  for  example,  it 
is  capable  of  representing  natural  number  induction  as  the  proposition: 

VP  :  Nat  — *  Prop.P  0  — >  (Vn  :  Nat,P  n  — *■  P  ( succ  n ))  — *  Vra  :  Nat,P  n 

When  a  quantified  formula  Vx.P  is  instantiated  with  an  object  d  using  the  rule  VElim,  we  get  a  proof  of 
P[d /x] .  The  notation  [d / x]  represents  standard  capture-avoiding  substitution,  defined  in  Figure  3.4. 

There  are  three  different  types  of  constants;  their  types  are  determined  from  the  signature  context. 
Constants  denoted  as  cy  correspond  to  the  domains  of  discourse  such  as  natural  numbers  (written  as  Nat), 
ordinals  (written  as  Ord )  and  lists  (written  as  List).  Constant  domain  objects,  denoted  as  ty  are  used  for 
constructors  of  these  domains  (for  example,  zero  :  Nat  and  succ  :  Nat  — *  Nat  for  natural  numbers);  for 
functions  between  objects  (for  example,  plus  :  Nat  — *  Nat  — *  Nat  for  the  addition  function  of  natural 
numbers);  for  predicates  (e.g.  le  :  Nat  — >  Nat  — *  Prop  for  representing  when  one  natural  number  is 
less-than-or-equal  to  another);  and  for  logical  connectives,  which  are  understood  as  functions  between 
propositions  (e.g.  logical  conjunction,  represented  as  and :  Prop  — >  Prop  —*■  Prop).  Constant  proof  objects, 
denoted  as  cn,  correspond  to  axioms.  The  constants  above  get  their  expected  meaning  by  adding  their 
corresponding  set  of  axioms  to  the  signature  -  for  example,  logical  conjunction  has  the  following  axioms: 

andlntro  :  VP1;  P2  :  Prop.P j  — *■  P2  — >  and  P,  P2 
andEliml :  VPj,P2  :  Prop. and  P,  P2  — *  Px 
andElim2  :  VPj,P2  :  Prop. and  P,  P2  — *■  P, 

Our  logic  supports  inductive  definitions  of  domains  and  predicates,  in  a  style  similar  to  CIC.  We  do 
not  represent  them  explicitly  in  the  logic,  opting  instead  for  viewing  such  definitions  as  generators  of  a 
number  of  ‘safe  to  add’  constants.  The  logic  we  have  presented  -  along  with  the  additions  made  below  -  is 
a  subset  of  CIC.  It  has  been  shown  in  Werner  [1994]  that  CIC  is  a  consistent  logic;  thus  it  is  understood 
that  the  logic  we  present  is  also  consistent,  when  the  signature  E  is  generated  only  through  such  inductive 
definitions.  We  will  present  more  details  about  inductive  definitions  after  we  make  some  extensions  to 
the  core  of  the  logic  that  we  have  presented  so  far. 

A  simple  example  of  a  proof  object  for  commutativity  of  conjunction  follows. 

AP  :  Prop. ATI  '■  Ptop.AH  :  A  P  Q. 
andlntro  Q  P  ( andElim2  P  Q  H )  ( andEliml  P  Q  H) 
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b  E  wf  well-formedness  of  signatures 

bv  $  wf  well-formedness  of  contexts 

<i>  by  K, :  Type  well-formedness  for  kinds 
$  by  d  :  JC  kinding  of  domain  objects 

•kbvTT  :  P  valid  logical  derivations  of  proof  objects  proving  a  proposition 


b  E  wf 


b  •  wf 


b  E  wf  cK  :  Type  E 
b  E,  Cfc  :  Type  wf 


b  E  wf  •  b  s  /C  :  Type  ^  E 

b  E,  cj  :  K,  wf 


b  E  wf  •  bE  P  :  Prop  cn  :  _  ^  E 
b  E,  cn:P  wf 


bs  $  wf 


b$wf  b  wf  b  /C  :  Type  b  $  wf  $  b  P :  Prop 

b  •  wf  b  $,  %  :  Type  wf  b  %  :  K,  wf  b  $,  %  :  P  wf 


$  bs  /C  :  Type 


Cjc  :  TJPe  e  s 

$  b  :  Type  $  b  /C2  :  Typi 

$  b  Prop  :  Type  $  bs  :  Type 

$  b  /C1  — >  /C2  :  Type 

$  by  d:K 

$  b  Pj  :  Prop  T  b  P2  :  Prop 

$  b  /C  :  Type  $,  %  :  /C  b  P  :  Prop 

$  b  Pj  — *■  P2  :  Prop 

b  /C  :  Type  4>,  x  :  1C  b  d  :  K,' 

$  b  V%  :  /C.P  :  Prop 

$  b  ^  :  £'  ->  K  §Vd2-.K! 

$  b  d%  :  /C.c/ :  K  -+  K! 

$  b  c/j  c/2  :  K, 

x  :/CG$ 

Cd'-T^T 

$  b  x  :  /C 

$  bs  Cflr  :  /C 

Figure  3.2:  The  typing  rules  of  the  logic  dHOL 
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$  by.  n  :  P 


$  b  P  :  Prop  4>,  x  :  P  h  n  :  P' 
$  b  Ax  :  P.7i :  P  —*  P' 

$  b  /C  :  Type  <5,  %  :  1C  b  n  :  P 


->Intro 


$  b  Ti y  :  P'  — >  P  $  b  7i2  :  P' 


$  b  Ax  :  K.n  :  Vx  :  fC.P 


VlNTRO 


$  b  ttj  tt2  :  P 

$  b  71 :  Vx  :  IC.P  $  b  d :  K 


$\~  7i  d  :  P[d /x] 


VElim 


Cn'-P^ 
$Kcn:P 


■  Constant 


■*Elim 


x  :P  G  $ 
4>  b  x  :  P 


Figure  3.3:  The  typing  rules  of  the  logic  dHOL  (continued) 


d[d'/x\ 


fv(P]  -*•  P2)  =  fv(P\ )  Ufv(P2) 

fv(Vx:JC.P)  =  fa(P)  \  { x } 
fv(\x:K,.d )  =  fv(d)\{x} 

fv(d1d2)  =  fv(d1)Ufv(d2) 
fv{x)  =  {x} 

/^(crf)  =  0 


(P1^P2)[d/x\ 
(Vy  :  /C.P)[c/ /x] 
(dy  :  ]C.d')[d / x] 
(^i  d2)[d /x] 

(x) [d /x] 

(y) [d/x] 


Pj[c//x]  — ►  P2  \d /x  ] 

Vy  :  /C.P[d/x]  when  fu(P)  fl I  fv(d)  =  0  and  x^y 
Xy  :  JC.d'[d /x]  when  fv(d')  fl /h(d)  =  0  and  x  ^  y 
dl  [d / x]  d2[d /x] 

d 

y 

cd 


Figure  3.4:  Capture  avoiding  substitution 


VAR 
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Based  on  the  typing  rules,  it  is  simple  to  show  that  it  proves  the  proposition: 

VP  :  Prop.y  Q  :  Prop. and  ?Q->  and  Q  P 


3.2  Adding  equality 

The  logic  we  have  presented  so  far  is  rather  weak  when  it  comes  to  reasoning  about  the  total  functions 
inhabiting  /Cj  — >  /C2.  For  example,  we  cannot  prove  that  the  standard  /3-reduction  rule: 

(Ax  :  IC.d)  d'  —  d\d' /%] 

Moreover,  consider  the  case  where  we  have  a  proof  of  a  proposition  such  as  P(1  +  1).  We  need  to  be  able 
to  construct  a  proof  of  P( 2)  out  of  this,  yet  the  logic  we  have  presented  so  far  does  not  give  us  this  ability. 

There  are  multiple  approaches  for  adding  rules  to  logics  such  as  /HOL  in  order  to  make  equality  be¬ 
have  in  the  expected  way.  In  order  to  understand  the  differences  between  these  approaches,  it  is  important 
to  distinguish  two  separate  notions  of  equality  in  a  logic:  definitional  equality  and  propositional  equality. 
Definitional  equality  relates  terms  that  are  indistinguishable  from  each  other  in  the  logic.  Proving  that 
two  definitionally  equal  terms  are  equal  is  trivial  through  reflexivity,  since  they  are  viewed  as  exactly  the 
same  terms.  We  will  use  d1  =  d1  to  represent  definitional  logic.  Propositional  equality  is  an  actual  pred¬ 
icate  of  the  logic.  Terms  are  proved  to  be  propositionally  equal  using  the  standard  axioms  and  rules  of 
the  logic.  In  /HOL  we  would  represent  propositional  equality  through  propositions  of  the  form  dl  =  d2. 
With  this  distinction  in  place,  we  will  give  a  brief  summary  of  the  different  approaches  below. 

Explicit  equality.  In  the  HOL  family  of  logics,  as  used  in  systems  like  HOL4  [Slind  and  Norrish,  2008] 
and  Isabelle/HOL  [Nipkow  et  ah,  2002],  definitional  equality  is  just  syntactic  equality.  Any  equal¬ 
ity  further  than  that  is  propositional  equality  and  needs  to  be  proved  using  the  logic.  The  logic 
includes  a  rule  where  propositions  that  can  be  proved  equal  can  replace  each  other  as  the  type  of 
proof  objects.  Any  such  rewriting  needs  to  be  witnessed  in  the  resulting  proof  objects.  A  sketch  of 
the  typing  rule  for  this  axiom  is  the  following: 

$\~  n  :  P  $  b  n  :  P  =  P' 

$  b  conv  Tin  :  P1 

The  advantage  of  this  approach  is  that  a  type  checker  for  it  only  has  to  check  proofs  that  contain  all 
the  required  details  about  why  terms  are  equal.  It  is  therefore  extremely  simple,  keeping  the  trusted 
base  of  our  logic  as  simple  as  possible.  Still,  it  has  a  big  disadvantage:  the  proof  objects  are  very 
large,  as  even  trivial  equalities  need  to  be  painstakingly  proved.  It  is  possible  that  this  is  one  of  the 
reasons  why  systems  based  on  this  logic  do  not  generate  proof  objects  by  default,  even  though  they 
all  support  them. 

Intensional  type  theories.  Systems  based  on  Martin-Lof  intensional  type  theory,  such  as  Coq  [Barras 
et  ah,  2012]  and  Agda  [Norell,  2007],  have  an  extended  notion  of  definitional  equality.  In  these  sys¬ 
tems,  definitional  equality  includes  terms  that  are  identical  up  to  evaluation  of  the  total  functions 
used  inside  the  logical  terms.  In  order  to  make  sure  that  the  soundness  of  the  logic  is  not  compro¬ 
mised,  this  notion  of  evaluation  needs  to  be  decidable.  As  we  have  said,  terms  that  are  definitionally 


38 


equal  are  indistinguishable,  so  their  equality  does  not  need  to  be  witnessed  inside  proof  objects, 
resulting  in  a  big  reduction  in  their  size. 

The  way  that  this  is  supported  in  such  type  theories  is  to  define  an  equality  relation  R  based  on  some 
fixed,  confluent  rewriting  system.  In  Coq  and  Agda  this  includes  /3-conversion  and  '-conversion 
(evaluation  of  total  recursive  functions),  pattern  matching  and  unfolding  of  definitions.  This  equal¬ 
ity  relation  is  then  understood  as  the  definitional  equality,  by  adding  the  following  conversion  rule 
to  the  logic: 


$  h  71 :  P\  Pi  =R  P2 
3>  b  n  :  P 2 

The  benefit  of  this  approach  is  that  trivial  arguments  based  on  computation,  which  would  nor¬ 
mally  not  be  “proved”  in  standard  mathematical  discourse,  actually  do  not  need  to  be  proved  and 
witnessed  in  the  proof  objects.  Therefore  the  logic  follows  what  is  called  the  Poincare  principle 
(e.g.  in  Barendregt  and  Geuvers  [1999]).  One  disadvantage  of  this  approach  is  that  our  trusted  base 
needs  to  be  bigger,  since  a  type-checker  for  such  a  logic  needs  to  include  a  decision  procedure  for  the 
relation  R. 

Extensional  type  theories.  In  extensional  type  theories  like  NuPRL  [Constable  et  ah,  1986],  the  notion 
of  definitional  equality  and  propositional  equality  are  identified.  That  means  that  anything  that  can 
be  proved  equal  in  the  logic  is  seen  implicitly  as  equal.  A  typing  rule  that  sketches  this  idea  would 
be  the  following: 


$  b  n  :  P1  $  b  n  :  P1  =  P2 
$  b  Ti :  P 2 

The  advantage  of  this  approach  is  that  the  size  of  proof  objects  is  further  reduced,  bringing  them 
even  closer  to  normal  mathematical  practice.  Still,  theories  with  this  approach  have  a  big  disadvan¬ 
tage:  type-checking  proof  objects  becomes  undecidable.  It  is  easy  to  see  why  this  is  so  from  the 
above  typing  rule,  as  the  n  proof  object  needs  to  be  reconstructed  from  scratch  during  type  check¬ 
ing  time  -  that  is,  type  checking  depends  on  being  able  to  decide  whether  two  arbitrary  terms  are 
provably  equal  or  not,  an  undecidable  problem  in  any  meaningful  logic.  Implementations  of  such 
theories  deal  with  this  by  only  implementing  a  set  of  decision  procedures  that  can  decide  on  such 
equalities,  but  all  of  these  procedures  become  part  of  the  trusted  base  of  the  system. 

We  should  note  here  that  type  theories  such  as  CIC  and  NuPRL  support  a  much  richer  notion  of 
domain  objects  and  kinds,  as  well  as  a  countable  hierarchy  of  universes  above  the  Type  sort  that  we  sup¬ 
port.  For  example,  kinds  themselves  can  be  computed  through  total  functions.  In  these  cases,  the  chosen 
approach  with  respect  to  equality  also  affects  which  terms  are  typable.  Our  logic  is  much  simpler  and 
thus  we  will  only  examine  equality  at  the  level  of  domain  objects.  Still,  we  believe  that  the  techniques 
we  develop  are  applicable  to  these  richer  logics  and  to  cases  where  equality  at  higher  universes  such  as  the 
level  of  kinds  K,  is  also  available. 

We  want  zHOL  to  have  the  simplest  possible  type  checker,  so  we  choose  the  explicit  equality  version. 
We  will  see  how  to  recover  and  extend  the  benefits  of  the  conversion  rule  through  VeriML  in  Section  7. 1 . 
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Syntax  extensions 


(dom.obj.  and  prop.)  d,P  ::=•••  \d1=d2 

(proof  objects)  tc  ::=  refl  d  \  conv  tc  tc'  \  subst  (x  :  K..P )  tc  \  congLam  ( x  :  K.tc) 
|  congForall  (x  :  JC.n )  \  beta  (x  :  K.d)  d' 


$  bs  d  :  /C 


4>  b  dj  :  /C  4>  b  d2:K 
$  b  dt  =  d2  :  Prop 


$  bs  n  :  P 


$b  d:K 
$  b  refl  d  :  d  =  d 


$  b  n  :  P  $  b  P  :  Prop  $  b  tc  :  P  —  P' 
$  b  conv  tc  tc  :  P 


4>,  %  :  /C  b  P  :  Prop  $  b  n  :  dx  =  d?  $  b  dx :  /C 
$  b  subst  (x  :  fC.P)  n  :P[d1/x]  =  P[d.,/x] 

x  :  K.  b  n  :  dt  =  d2  4>,  x  :  1C  b  n  :  Px  =  P2  x  :  /C  b  P1:  Prop 

$  b  congLam  (x  :  fC.n) :  {Xx  :  fC.df)  =  {Xx  :  fC.df)  $  b  congForall  (x  :  IC.tc)  :  (Vx  :  fC.Pf)  =  (Vx  :  Kl.Pf) 

$  b  (Xx  :  JC.d) :  1C  ->  /C'  $b/:/C 

$  b  (x  :  /C.d)  d' :  ((dx  :  /C.d)  d1)  =  (d  [d^x]) 


Figure  3.5:  The  logic  dHOL£:  syntax  and  typing  extensions  for  equality 
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(sorts) 
(logical  terms) 


s 

t 


(variable  contexts)  $ 
(constant  signature)  £ 


Prop  |  Type  \  Type 

s  |  x  |  c  |  Vx  :  tvt2  |  dx  :  t1.t2  \  T  h  I  =  h  \  refl  t 
conv  t2  |  subst  (x  :  tfc.tp)  t  \  congLam  (x  :  t^.t) 
congForall  (x  :  tk.t)  \  beta  (x  :  t^.tj)  t2 

•  |  $,  x  :  t 

•  |  £ ,  c  :  t 


Figure  3.6:  The  syntax  of  the  logic  dHOL  given  as  a  PTS 

We  therefore  extend  our  logic  with  a  built-in  propositional  equality  predicate,  as  well  as  a  set  of  equality 
axioms.  The  extensions  required  to  the  logic  presented  so  far  are  given  in  Figure  3.5.  We  sometimes  refer 
to  dHOL  together  with  these  extensions  as  dHOL£  in  order  to  differentiate  with  a  version  that  we  will 
present  later  which  includes  the  conversion  rule;  that  version  is  called  dHOLc. 

Most  of  the  typing  rules  of  the  new  axioms  are  standard.  We  have  an  explicit  axiom  for  /3-reduction 
through  the  proof  object  constructor  beta,  ar-cqui  valence  is  handled  informally  at  this  level  by  implicitly 
identifying  terms  that  are  equal  up  to  renaming  of  bound  variables;  this  will  be  changed  in  the  next  section. 
Note  that  some  rules  seem  to  omit  certain  premises,  such  as  the  fact  that  P2  is  a  proposition  in  the  case  of 
congForall.  The  reason  is  that  these  premises  are  always  true  based  on  the  existing  ones;  in  the  example  at 
hand,  the  fact  that  l\  =  P2  implies  that  their  type  is  identical,  thus  P2  is  a  proposition  just  like  Pl  is. 

The  given  set  of  axioms  is  enough  to  prove  other  expected  properties  of  equality,  such  as  symmetricity: 

symm K  :  Na  :  /C.V b  :  1C.a  =  b  — *■  b  =  a 

symm^  —  Aa  :  JC.Ab  :  IC.AH  :  a  =  b.  conv(refl  a)  {subst  (x  :  IC.x  =a)  H) 

3.3  /IHOL  as  a  Pure  Type  System 

Our  presentation  of  dHOL  above  separates  the  various  different  types  of  logical  terms  into  distinct  classes. 
This  separation  results  in  duplicating  various  typing  rules  -  for  example,  quantification,  logical  implica¬ 
tion  and  function  kinds  share  essentially  the  same  type  and  term  formers.  This  needlessly  complicates  the 
rest  of  our  development.  We  will  now  present  dHOL  as  a  Pure  Type  System  [Barendregt,  1992]  which 
is  the  standard  way  to  describe  typed  lambda  calculi.  Essentially  the  syntactic  classes  of  all  logical  terms 
given  above  are  merged  into  one  single  class,  denoted  as  t.  We  give  the  new  syntax  in  Figure  3.6  and  the 
new  typing  rules  in  Figure  3.7.  Note  that  we  use  £,  — >  t2  as  syntactic  sugar  for  Vx  :  £j.£2  when  x  does  not 
appear  free  in  t2. 

A  PTS  is  characterized  by  three  parameters:  the  set  of  sorts,  the  set  of  axioms  and  the  set  of  rules.  These 
parameters  are  instantiated  as  follows  for  dHOL: 

S  =  {Prop,  Type,  Type} 

A  =  {{Prop, Type),  {Type, Type)} 

l Z  =  {{Prop, Prop, Prop),  {Type,  Type,  Type),  {Type, Prop, Prop)} 

Terms  sorted1  under  Prop  represent  proofs,  under  Type  represent  objects  (including  propositions)  and  un¬ 
der  Type  represent  the  domains  of  discourse  (e.g.  natural  numbers).  The  axiom  {Prop,  Type)  corresponds 

1.  That  is,  terms  typed  under  a  term  whose  sort  is  the  one  we  specify. 
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b  E  wf  well-formedness  of  signatures 
K:  $  wf  well-formedness  of  contexts 
$  bv  t  :  t'  typing  of  logical  terms 


b  E  wf 


b  •  wf 


bs  $  wf 


b  •  wf 


b  E  wf  • bE  t  :  s 
b  E,  x  :  t  wf 


b  $  wf  $  b  t  :  s 
b  x  :  t wf 


$  bE  t :  t' 


$  b  tx  :  s  4>,  %  :  tx  b  t2  :  s'  (s,s' ,s")  &7Z  $  b  :  Vx  :  t.t'  $  b  t2:t 


$bs:s/  $bVx:t1.t2:j/ 

4>,  %  :  £j  b  t2  :  t'  $  b  Vx  :  tvt' :  s 
$  b  Ax  :  t1.t2  :  Vx  :  tvt' 

$  b  fj :  t  $  b  t2:  t  4>  b  £  :  Type 
$  b  fj  =  t2  :  Prop 


x:te$ 


$  b  t1  t2  :  t'[t2/x\ 
c  :t  e  E 


$ bs  c  :  t 


$  b  x  :  t 

$  b  t :  t'  $  b  t' :  Type 


$  b  reft  t  :  t  =  t 


$  b  tj  :  t  $  b  t  :  Prop  $  b  t2:  t  =  t1 
$  b  conv  t\  t2  :  t 


^  b  tk:  Type  $,x:tk\~tP:  Prop  $\~t:ta  =  tb  $\~ta:tk 
$  b  subst  (x  :  tb.tP)  t  :  tP[ta/x\  =  tP[tb/x\ 

$  b  :  Type  x  :  b  t  :  tx  =  t2 

$  b  congLam  (x  :  t^.t) :  (Ax  :  =  (Ax  :  tb.t2) 

$  b  :  Type  x  :  b  t :  tx  =  t2  3>,  x  :  b  tx :  Prop 

$  b  congPorall  (x  :  tk.t) :  (Vx  :  tk.tx)  =  (Vx  :  tk.t2) 

$\-(Ax:ta.tx):ta^>tb  ta-*tb:Type  $  b  t2  :  ta 

$  b  (x  :  ta.tx)  t2  :  ((Ax  :  ta.tx)  t2)  =  (t1[t2/*]) 


Figure  3.7:  The  typing  rules  of  the  logic  AHOL  in  PTS  style 
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to  the  fact  that  propositions  are  objects  of  the  domain  of  discourse,  while  the  axiom  (Type,  Type  )  is  essen¬ 
tially  what  allows  us  to  introduce  constants  and  variables  for  domains.  The  rules  are  understood  as  logical 
implication,  function  formation  between  objects  and  logical  quantification,  respectively.  Based  on  these 
parameters,  it  is  evident  that  dHOL  is  similar  to  System  F co,  which  is  usually  formulated  as  S  =  {*,□}, 
A  ={(*,□)},  TZ  =  {(★,*,*),  (□,□,□),  (□,*,*)}.  dHOL  is  a  straightforward  extension  with  an  extra  sort 
above  □  -  that  is,  Type  above  Type  -  allowing  us  to  have  domains  other  than  the  universe  of  propositions. 
Furthermore,  dHOL  extends  the  basic  PTS  system  with  the  built-in  explicit  equality  as  presented  above, 
as  well  as  with  the  signature  of  constants  S. 

The  substitution  lemma 

The  computational  language  of  VeriML  assumes  a  simple  set  of  properties  that  need  to  hold  for  the  type 
system  of  the  logic  language.  The  most  important  of  these  is  the  substitution  lemma,  stating  that  sub¬ 
stituting  terms  for  variables  of  the  same  type  yields  well-typed  terms.  We  will  prove  a  number  of  such 
substitution  lemmas  for  different  notions  of  ‘term’  and  ‘variable’.  As  an  example,  let  us  state  the  substitu¬ 
tion  lemma  for  logical  terms  of  dHOL  in  the  PTS  version  of  the  logic. 

Lemma  3.3.1  (Substitution)  If<&,  x  :  t'T,  &  b  t  :  tT  and <5  b  t1 :  t'T  then  4>,  ^[V/x]  b  £[V/x]  :  tT[t' /x]. 


The  proof  of  the  lemma  is  a  straightforward  induction  on  the  typing  derivation  of  the  term  t .  The  most 
important  auxiliary  lemma  it  depends  on  is  that  typing  obeys  the  weakening  structural  rule,  that  is: 

Lemma  3.3.2  (Weakening)  If$  b  t  :tr  then  $,  x  :  t'T  b  t  :  tT. 

The  substitution  lemma  can  alternatively  be  stated  for  a  list  of  substitutions  of  variables  to  terms,  covering 
the  whole  context.  This  alternative  statement  is  technically  advantageous  in  terms  of  how  the  proof  is 
carried  through  and  also  how  the  lemma  can  be  used.  The  lemma  is  stated  as  follows: 

Lemma  3.3.3  (Simultaneous  substitution)  Ifx  x  :  tx,  x2,  t2,  ■  ■  ■  ,  xn  :  tn  b  t  :  tT  and  for  all  i  with  1  <  i  < 
n,  $'\~  xt:  tj,  then  b  t[tl,t2,--  ,t„/xl,x2,---  ,xj. 

We  can  view  the  list  of  (x-,  £■)  variable-term  pairs  as  a  well-typed  substitution  covering  the  context  T.  We 
will  give  a  more  precise  definition  of  this  notion  in  the  following  section. 

For  the  rest  of  our  development,  we  will  switch  to  a  different  variable  representation,  which  will 
allow  us  to  state  these  lemmas  more  precisely,  by  removing  the  dependence  on  variable  names  and  the 
requirement  for  implicit  a-renaming  in  the  definition  of  substitution.  Thus  we  will  not  go  into  more 
details  of  these  proofs  as  stated  here. 

3.4  /IHOL  using  hybrid  deBruijn  variables 

So  far,  we  have  used  names  to  represent  variables  in  dHOL.  Terms  that  are  equivalent  up  to  a-renaming 
are  deemed  to  be  exactly  the  same  and  are  used  interchangeably.  An  example  of  this  shows  up  in  the  def¬ 
inition  of  capture-avoiding  substitution  in  Figure  3.4:  constructs  that  include  binders,  such  as  Xy  :  IC.d, 
are  implicitly  a: -renamed  so  that  no  clashes  with  the  variables  of  the  subsitutend  are  introduced.  We  are 
essentially  relying  on  viewing  terms  as  representatives  of  their  ^-equivalence  classes;  our  theorems  would 
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also  reason  up  to  this  equivalence.  It  is  a  well-known  fact  [Aydemir  et  al.,  2008]  that  when  formally  prov¬ 
ing  such  theorems  about  languages  with  binding  in  proof  assistants,  identifying  terms  up  to  ^-equivalence 
poses  a  large  number  of  challenges.  This  is  usually  addressed  by  choosing  a  concrete  variable  representation 
technique  where  the  non-determinism  of  choosing  variable  names  is  removed  and  thus  all  a-equivalent 
terms  are  represented  in  the  same  way. 

We  have  found  that  using  a  similar  concrete  variable  representation  technique  is  advantageous  for  our 
development,  even  though  our  proofs  are  done  on  paper.  The  main  reason  is  that  the  addition  of  contex¬ 
tual  terms,  contextual  variables  and  polymorphic  contexts  introduces  a  number  of  operations  which  are 
hard  to  define  in  the  presence  of  named  variables,  as  they  trigger  complex  sets  of  or-renamings.  Using  a 
concrete  representation,  these  operations  and  the  renamings  that  are  happening  are  made  explicit.  Fur¬ 
thermore,  we  use  the  same  concrete  representation  in  our  implementation  of  VeriML  itself,  so  the  gap 
between  the  formal  development  and  the  actually  implemented  code  is  smaller,  increasing  our  confidence 
in  the  overall  soundness  of  the  system. 

The  concrete  representation  technique  that  we  use  is  a  novel,  to  the  best  of  our  knowledge,  combi¬ 
nation  of  the  techniques  of  de  Bruijn  indices,  de  Bruijn  levels  [De  Bruijn,  1972]  and  the  locally  nameless 
approach  [McKinna  and  Pollack,  1993],  The  former  two  techniques  replace  all  variables  by  numbers, 
whereas  the  locally  nameless  approach  introduces  a  distinction  between  bound  and  free  variables  and 
handles  them  differently.  Let  us  briefly  summarize  these  approaches  before  presenting  our  hybrid  repre¬ 
sentation.  A  table  comparison  is  given  in  Table  3.1.  DeBruijn  indices  correspond  to  the  number  of  binders 
above  the  current  variable  reference  where  the  variable  was  bound.  DeBruijn  levels  are  the  “inverse”  num¬ 
ber,  corresponding  to  how  many  binders  we  have  to  cross  until  we  reach  the  one  binding  the  variable  we 
are  referring  to,  if  we  start  at  the  top  of  the  term.  Both  treat  free  variables  by  considering  the  context  as  a 
list  of  variable  binders.  In  both  cases,  when  performing  the  substitution  (\y  .t)\t' / x],  we  need  to  shift  the 
variable  numbers  in  t'  in  order  for  the  resulting  term  to  be  well-formed  -  the  free  variables  in  the  indices 
case  or  the  bound  variables  in  the  levels  case.  In  the  indices  case,  the  introduction  of  the  new  binder  alters 
the  way  to  refer  to  the  free  variables  (the  free  variable  represented  by  index  n  in  t'  will  be  represented  by 
n  +  1  under  the  /-abstraction),  as  the  identities  of  free  variables  directly  depend  on  the  number  of  bound 
variables  at  a  point.  In  the  levels  case,  what  is  altered  is  the  way  we  refer  to  bound  variables  within  t ' 
-  the  ‘allocation  policy’  for  bound  variables  in  a  way.  For  example  the  lambda  term  t '  —  Xx.x  that  was 
represented  as  X.n  outside  the  new  binder  is  now  represented  as  X.n  +  1.  This  is  problematic:  substitution 
is  not  structurally  recursive  and  needs  to  be  reasoned  about  together  with  shifting.  This  complicates  both 
the  statements  and  proofs  of  related  lemmas. 

The  locally  nameless  approach  addresses  this  problem  by  explicitly  separating  free  from  bound  vari¬ 
ables.  Free  variables  are  represented  normally  using  names  whereas  deBruijn  indices  are  reserved  for 
representing  bound  variables.  In  this  way  the  identities  of  free  variables  are  preserved  when  a  new  binder 
is  introduced  and  no  shifting  needs  to  happen.  We  still  need  two  auxiliary  operations:  freshening,  in  or¬ 
der  to  open  up  a  term  under  a  binder  into  a  term  that  has  an  extra  free  variable  by  replacing  the  dangling 
bound  variable,  and  binding,  which  is  the  inverse  operation,  turning  the  last-introduced  free  variable  into 
a  bound  variable,  so  as  to  close  a  term  under  a  binder.  Under  this  approach,  not  all  a-equivalent  terms  are 
identified,  as  using  different  names  for  free  variables  in  the  context  still  yields  different  terms. 

We  merge  these  approaches  in  a  new  technique  that  we  call  hybrid  deBruijn  variables:  following  the 
locally  nameless  approach,  we  separate  free  variables  from  bound  variables  and  use  deBruijn  indices  for 
bound  variables  (denoted  as  bt  in  Table  3.1);  but  also,  we  use  deBruijn  levels  for  free  variables  instead  of 
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Example  of  performing  the  substitution: 
(Ay  :  x.f  y  a)\_(Az  :  x.z)y /a\ 


Free  variables  context: 

%  :  Type ,  g  x,  y  :  x,  a  :  x 


Named  representation  (Ay  :  x.g  y  a)\_(Az  :  x.z)y/a\ 

(Aw  :  x.g  w  a)[(Az  \  x.z)y /a\  =a 

Aw  :  x.g  w  ((Az  :  x.z)  y)  => 


deBruijn  indices 

(d(3).3  0  l)[(d(3).0)  1/0] 
d(3).3  0  (shiftFree  ((d(3).0)  1)) 

d(3).3  0((d(4).0)2) 

deBruijn  levels 

(d(0).l  4  3)[(d(0).4)  2/3] 
d(0).  1  4  (shiftBound  ((d(0).4)  2)) 

d(0).14((d(0).5)2) 

Focally  nameless 

(d(x).g  0 a)[(A(x).0) y / a\ 
A(x).g0((A(x).0)y) 

Hybrid  deBruijn 

(Kv 0)-H  b0  Vt)[(A(vq)\)  v2/v2] 
A(v0).v1  b0((A(v0).b0)v2) 

Table  3.1:  Comparison  of  variable  representation  techniques 


s  ::=  Prop  \  Type  \  Type 

t::=s\c\vi\  b,  \  A(tx).t2  \t1t2\  n  (tx).t2  \t1  =  t2 

|  conv  t]  t2  |  subst  ((tk).tP)  t  |  refl  t  \  congLam  ((tk).t) 
|  congForall ((t^).t)  \  beta((t^).t^)  t2 
E  ::=  •  |  E,  c  :  t 
$::=•!  $,  £ 
a  ::=  •  |  a,  t 


Figure  3.8:  The  logic  /HOL  with  hybrid  deBruijn  variable  representation:  Syntax 

names  (denoted  as  vt).  In  this  way,  all  or-equi valent  terms  are  identified.  Furthermore,  terms  preserve 
their  identity  under  additions  to  the  end  of  the  free  variables  context.  Such  additions  are  a  frequent 
operation  in  VeriMF,  so  this  representation  is  advantageous  from  an  implementation  point  of  view.  A 
similar  representation  technique  where  terms  up  to  any  weakening  of  the  context  are  identified  (not  just 
additions  to  the  end  of  the  context)  by  introducing  a  distinction  between  used  and  unused  variable  names 
has  been  discovered  independently  by  Pollack  et  al.  [2011]  and  Pouillard  [2011], 

Fet  us  now  proceed  to  the  presentation  of  dHOF  using  our  hybrid  representation  technique.  We 
give  the  new  syntax  of  the  language  in  Figure  3.8,  the  new  typing  rules  in  Figures  3.9  and  3.10  and  the 
definition  of  syntactic  operations  in  Figures  3.11,  3.12  and  3.13. 

As  expected,  the  main  change  to  the  syntax  of  terms  and  of  the  context  $  is  that  binding  structures 
do  not  carry  variable  names  any  longer.  For  example,  instead  of  writing  Ax  :  tl.t2  we  now  write  A(Ll).t2- 
In  the  typing  rules,  the  main  change  is  that  extra  care  needs  to  be  taken  when  going  into  a  binder  or 
when  enclosing  a  term  with  a  binder.  This  is  evident  for  example  in  the  rules  IIType  and  IIlNTRO.  When 
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b  E  wf 


- SigEmpty 

b  •  wf 


bs  $  wf 


-  CtxEmpty 

b  •  wf 


4>  b  a  : 


b  $  wf 

- SubstEmpty 

$  b  •  :  • 


^bs f.t ' 


c:te  E 

- Constant 

$  bs  c  :  t 


b  E  wf 


•  by  t :  s  (c  :  WE 

- - - SigConst 

b  E, c  :  t  wf 


b  $  wf  $  b  t :  s 

-  CtxVar 

b  <£>,  t  wf 


b  <r  :  4b  $  b  t  :t  •  a 

- 7 - 7 -  SUBSTVAR 

$  b  a,  t  :  (4b,  t  ) 


4>.z  =  t 

- VAR 

$  b  Vj  :t 


(s,s  )  G  A 

- -  Sort 

$  b  s  :  s' 


$  b  tj  :  5 


(s,s',s")en 

- — - 77 - IIType 

$  b  II (t^).t2  :  s 


$  b  tx :  s 


$bn(ii).  L^J|$|+i  :s' 

®  b  A(tl).t2  :  n(jj). 


niNTRO 


$  b  t,  :  II (t).t'  $  b  t2‘t 

- - - — - - —  nELiM 

$  I"  h  h :  M  |$|  •  («**>  h) 


4>  b  tx  :  t 


$  b  t2  :  t  $  b  t :  Type 
$  b  f  j  =  t2  ■  Prop 


EqType 


Figure  3.9:  The  logic  bHOL  with  hybrid  deBruijn  variable  representation:  Typing  Judgements 
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$  h  £.  :  t  $  b  t,  =  £.  :  Prop 

- - - - - - - -  EqRefl 

$  b  re/7  £t :  tl  =  £j 


$  h  £  :  £j  $  h  :  Prop  3>  b  t  :  t1  =  t2 

- - - EqElim 

$  b  co«f  t  t  :t2 


$\-tk:  Type  $,  tk  b  f  iP]|$|  :  Prop  $  h  t :  =  t* 

$  b  s«fe£  ((tk).tP )  £  :  £P  •  («/$,  tj  =  £P  •  (zd$,  4) 


$  h  *<  =  h 


EqSubst 


$  h  ^  :  Type  $,  tk\~  \t]m:  t^  =  t2 

- — - EqLam 

$  b  congLam  ((tk).t) :  (A(tk).  LpJ|$|+1)  =  (Kh)-  L^J|$|+i) 

$  h  ^  :  Type  $,  tk  b  f £l$|  :  £,  =  £2  $,  h  ^  T :  ProP 

- — - EqForall 

$  b  congForall  ((tk).t) :  (V(tA).  LtiJ|*|+i)  =  (V(t*).  L^J|$|+i) 


$  K^(U-T) :  ^  4  $\-  ta-+tb:Type  $\~t2:ta 

$  b  7>eto  ((tJ.tj)  £2  :  ((^tJ.tj)  t2)  =  r til|*| '  (id9,  t2) 


EqBeta 


Figure  3.10:  The  logic  dblOL  with  hybrid  deBruijn  variable  representation:  Typing  Judgements  (contin¬ 
ued) 

we  cross  a  binder,  the  just-bound  variable  b0  needs  to  be  converted  into  a  fresh  free  variable.  This  is 
what  the  freshening  operation  \t\‘m  does,  defined  in  Figure  3.11.  The  two  arguments  are  as  follows:  n 
represents  which  bound  variable  to  replace  and  is  initially  0  when  we  leave  it  unspecified;  m  is  the  current 
number  of  free  variables  (the  length  of  the  current  context),  so  that  the  next  fresh  free  variable  vm  is 
used  as  the  replacement  of  the  bound  variable.  Binding  is  the  inverse  operation  and  is  used  when  we  are 
re-introducing  a  binder,  capturing  the  last  free  variable  and  making  it  a  bound  variable.  The  arguments 
are  similar:  n  represents  which  bound  variable  to  replace  with  and  m  represents  the  level  of  the  last  free 
variable. 

As  is  evident  in  the  above  discussion,  the  operations  of  freshening  and  binding  have  particular  assump¬ 
tions  about  the  terms  they  are  applied  to.  For  example,  freshening  needs  to  be  applied  to  a  term  with  one 
“dangling”  bound  variable,  whereas  binding  needs  to  be  applied  to  a  closed  term.  In  order  to  state  such 
assumptions  precisely,  we  define  the  notion  of  free  and  bound  variable  limits  in  Figure  3.12.  We  say  that 
a  term  £  obeys  the  limit  of  n  free  variables,  and  write  t  </  n  when  £  does  not  contain  any  free  variable 
higher  than  vn_v  Bound  variable  limits  are  similar. 

We  have  also  changed  the  way  we  denote  and  perform  substitutions.  We  have  added  simultaneous 
substitutions  as  a  new  syntactic  class.  We  denote  them  as  a  and  refer  to  them  simply  as  substitutions  from 
now  on.  They  represent  lists  of  terms  to  substitute  for  the  variables  in  a  $  context.  Notice  that  the  lack 
of  variable  names  requires  that  both  $  and  a  are  ordered  lists  rather  than  sets.  The  order  of  a  substitution 
a  needs  to  match  the  order  of  the  context  that  it  corresponds  to.  This  is  made  clear  in  the  definition  of 
the  operation  of  applying  a  substitution  to  a  term,  written  as  t  ■  a  and  given  in  Figure  3.13.  In  essence, 
substitution  application  is  a  simple  structural  recursion,  the  only  interesting  case2  being  the  replacement 

2.  As  a  notational  convenience,  we  mark  such  interesting  cases  with  a  star. 


47 


Freshening:  \t~\nm 


* 

* 


* 

* 


\s]n 

1  1  m 

= 

s 

[cf 

i  i  m 

= 

c 

\vAn 

l  l  1  m 

= 

vt 

\b  Y 

i  n  \m 

= 

vm 

= 

bi 

r  {Kh).t2)rm 

= 

Whrj.\t2rm+1 

rn  hrm 

= 

m:  \h\nm 

\^h).t2)r 

= 

n(r^rj.(r^i:+1) 

*-+ 

ii 

s  s 

= 

3“ » 

II 

3  s 

\conv  t:  t2 1” 

= 

conv  \t,]n  \t2]n 

1  1  1  yyi  1  Z.  1  m 

\reflt]n 

1  J  1  m 

= 

refl  [t] 

\subst(tk.tP)t]nm 

= 

\congLam(tk.t)]nm 

= 

congUm(  M"m.U]T> 

\congForall  {tk.t)Ym 

= 

congFomtt(\ttTm.\tY+" 

\beta(tk.tx)t2  ]nm 

= 

\hl 

Binding:  [t J” 


[s\n 

L  J  m 

= 

s 

= 

c 

K-iJ” 

= 

bn 

[V:\n 

L  l  J  m 

= 

vi 

lh\nm 

= 

bi 

m,)-h)\nm 

= 

KYh\nm)Ah\T 

Ui  h\nm 

= 

L^iJ*  Ml 

[n{h).t2)\nm 

= 

n^O-L^C1 

ih=h\nm 

= 

3""* 

II 

[conv  tt  t2 J” 

= 

UiJ:  \h\nm 

= 

refl  fl\nm 

[swfctfo.tpjtj” 

= 

subst([tk\nm.[tP\nm+1)  [t\ 

[congLam  (tk.t)\nm 

= 

congLam  ([tk\nm.[t\n+l) 

[congFora.il  (tk.t) J” 

= 

congForall([tk\nm.[t\n+]] 

= 

beta{[tk\nm.[h\n+')  [t2\\ 

Figure  3.11:  The  logic  /HOL  with  hybrid  deBruijn  variable  representation:  Freshening  and  Binding 
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Free  variable  limits  for  terms: 
t  <f  n 


s  <f  n 
c  <f  n 
Vj  <f  n 
bt  <f  n 

{Kh)-h)  <f  n 

tx  t2  n 


■<=  n  >  i 

4=  t-y<f  n  At2  <f  n 
4=  t1  <f  n  A  t2  <f  n 


Free  var.  limits  for  substitutions: 
o  <f  n 


•  <f  n 

( a,t)<f  n  4=  a<f  n/\t<f  n 


Bound  var.  limits  for  terms: 
t  <h  n 


s  n 
c  <h  n 
vi  <h  n 
bi  <h  n 

{Kh)-h)<b  n 

t1  t2  <b  n 


4=  n  >  i 

4=  t1  <b  n  A  t2  n  +  1 
4=  tj  <b  n  A  t2  <b  n 


Bound  var.  limits  for  substitutions: 
a  n 


•  <b  n 

( a,t)<bn  4=  a<hnAt<bn 


Figure  3.12:  The  logic  dHOL  with  hybrid  deBruijn  variable  representation:  Variable  limits 
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Substitution  application:  t  ■  a 


s  ■  o 
c  ■  a 
*  v  l  ■  a 
bra 

(h  h)-a 

(n(ti  )-t2)-° 

(*i  =  h)-(J 
(conv  tx  t2 )  •  cr 
( refl  t )  ■  a 
( subst  (tfc.tp)  t )  •  a 
( congLam  (t^.t))  ■  a 
( congForall  (t^.t))  •  a 
(beta  (t^.tf)  t2 )  ■  o 


—  s 
=  c 
=  a.i 

=  h 

=  X(tra).(t2-a) 

=  ih  ■  a)  (h  '  a) 

=  n  (tva).(t2-a) 

=  =  r°) 

—  conv  (t1-  a)  (t2-  a) 

=  refl  (t  ■  a) 

=  subst  (tfc  ■  a.tp  ■  a)  (t  ■  a) 
=  congLam  (tk  ■  a.t  ■  a) 

=  congForall (tfc  ■  a .t  ■  a) 

=  beta  (tk  ■  a.t{  ■  a)  (t2  ■  cr) 


Substitution  application:  a  ■  a' 


•  ■  a 

(a,  t)  ■  a 


(a  -  a),  (t  ■  a) 


Identity  substitution:  id§ 
id,  =  • 


Figure  3.13:  The  logic  dHOL  with  hybrid  deBruijn  variable  representation:  Substitution  Application  and 
Identity  Substitution 
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of  the  z-th  free  variable  with  the  z-th  term  of  the  substitution.  It  is  evident  that  substitution  cannot  be 
applied  to  terms  that  use  more  free  variables  than  there  are  in  the  substitution.  It  is  simple  to  extend 
substitution  application  to  work  on  substitutions  as  well.  This  operation  is  written  as  a  ■  a' . 

When  using  names,  typing  rules  such  as  IIELIM  made  use  of  substitution  of  a  single  term  for  the  last 
variable  in  the  context.  Since  we  only  have  full  substitutions,  we  use  the  auxiliary  definition  of  the  identity 
substitution  id§  for  a  context  $  given  in  Figure  3.13  to  create  substitutions  changing  just  the  last  variable 
of  the  context.  Therefore  where  we  previously  used  t[t' /x]  we  now  use  t  ■  (id$,  t'). 

Also  in  Figure  3.9  we  have  added  a  new  typing  judgement  in  order  to  classify  substitutions,  denoted  as 
4b  b  o  :  $  and  stating  that  the  substitution  a  covers  the  context  $  whereas  the  free  variables  of  the  terms 
in  a  come  from  the  context  4>'.  The  interesting  case  is  the  SubstVar  rule.  An  initial  attempt  to  this  rule 
could  be: 

4b  b  a  :  $  t  :  t' 

- SubstVar? 

^h((r,  £):($,  t ') 

However,  this  version  of  the  rule  is  wrong  in  cases  where  the  type  of  a  variable  in  the  context  $  mentions 
a  previous  variable,  as  in  the  case:  $  =  %  :  Type ,  y  :  x.  If  the  substitution  instantiates  %  to  a  concrete  kind 
like  Nat  then  a  term  substituting  y  should  have  the  same  type.  Thus  the  actual  SubstVar  rule  expects  a 
term  whose  type  matches  the  type  of  the  variable  in  the  context  after  the  substitution  has  been  applied. 
Indeed  it  matches  the  wrong  version  given  above  when  no  variable  dependence  exists  in  the  type  t'. 

Metatheory 

We  are  now  ready  to  state  and  prove  the  substitution  lemma,  along  with  a  number  of  important  auxiliary 
lemmas  and  corollaries3 . 

Lemma  3.4.1  (Identity  substitutions  are  well-typed) 

b  $  wf  4>x  =  4>,  tv  t2,  ••• ,  tn  V^'wf 
4b  b  id§  :  $ 


Proof.  By  structural  induction  on  4>.  □ 

Lemma  3.4.2  (Interaction  between  freshening  and  substitution  application) 

t  <f  m  a  </  m!  \a\  =  m 

vm') 


Proof.  By  structural  induction  on  t.  □ 

Lemma  3.4.3  (Interaction  between  binding  and  substitution  application) 

t  <f  m  +  1  a  <t  m!  |u|  —  m 

3.  The  interested  reader  can  find  more  detailed  versions  of  these  proofs  in  our  published  Technical  Report  [Stampoulis  and 
Shao,  2012b]. 
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□ 


Proof.  By  structural  induction  on  t. 

Lemma  3.4.4  (Substitutions  are  associative)  (t  ■  a)  ■  o'  —  t  ■  (cr  ■  a') 

Proof.  By  structural  induction  on  t.  □ 

Theorem  3.4.5  (Substitution) 


4>  b  t  :t'  h  (7  :  $ 

4b  b  t  ■  a  :  t'  ■  a 

Proof.  By  structural  induction  on  the  typing  derivation  for  t.  We  prove  three  representative  cases. 

Case  IIType. 

/$b  tl:s  <F,  tl  b  ft2l|$|  :s'  (s,s',s")eTl^ 

\  $b  Ii(tx).t2:s"  j 

By  induction  hypothesis  for  tx  we  get: 

4b  b  tx  •  cr  :  s. 

By  induction  hypothesis  for  4>,  t{  b  :  s'  and  tx-  o\~  (a,v  |$/|) :  (4>,  tx)  we  get: 

tx-o  b  rt2l|*| '  (o-W|$'|) :  s'  ■ 

We  have  s'  =  s'  ■  (a,  t>|$/|)  trivially. 

Also,  we  have  that  f  t2l|^|  •  (cr,ty|)  =  \t2-a\#y 
Thus  by  application  of  the  same  typing  rule  we  get: 

4>7  b  •  o).(t2  ■  cr) :  s" . 

This  is  the  desired,  since  (n(t1).t2)  •  0  —  n(^  •  cr ).(t2  ■  a). 

Case  IIIntro. 

/$btj:s  t1\-\t2]l^-.t'  ^  b n(tj).  [t'J |^|+1 :  s'N 

\  $  b  \(tx).t2  :  n(tj).  [f'J  |$|+1  j 

Similarly  to  the  above. 

From  the  induction  hypothesis  for  t]  and  t2  we  get: 

$'b  tx  ■  a  :  s  and  &  ,tx  ■  a  b  \t2-o]  ^  :  t'  -{a, 

From  the  induction  hypothesis  for  II(t1).  [FJ  we  get: 

4b  b  (F^ij).  |$|+1)  •  cr :  s',  or  equivalently 

4>/bn(r,  l$+1|  •  a) :  s',  which  further  rewrites  to 

$/bn(v4  [*'  -(o-»vi)J  i$'i+i :5/- 

We  can  now  apply  the  same  typing  rule  to  get: 
b  A(tx  ■  cr).(t2  ■  a) :  Ilfo  •  cr).  [; t '  •  (cr,  v^)\  |$/|+1- 

We  have  Ilfo  •  cr).  [; t '  •  (cr,  ty|)J  |$/|+1  =  Ilfo  •  cr).((  [t' J  |$|+1)  •  cr)  =  (Ilfo).  |/J  m+1)  •  0,  thus  this  is  the 
desired  result. 
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Case  IIElim. 


/  $  b  tj  :  $  b  t2  :  t  ^ 

\ $  h  ht2  ■  r*'i  |$|  •  («**>  f2) ) 

By  induction  hypothesis  for  £,  and  t2  we  get: 

4b  h  tj  •  a  :  II(£  •  a).(t '  ■  a). 

&  h  t2  ■  a  '■  t  ■  a . 

By  application  of  the  same  typing  rule  we  get: 

&  1“  Oi  h) '  °  '■  K-l  |$'| '  («4'>  h>  • 

We  have  that  |"  t'  ■  ■  (id^,t2  ■  a)  =  ( |Y]  ^  •  {a,v^)  ■  (id#,  t2-a)=  \  t ']  ^  ■  (id#,  t2  ■  a)). 

But  (a,  t2|$/|)  •  (id&,  t2-  a)  =  a,  (t2  ■  a). 

Thus  we  only  need  to  show  that  |" t'~\  ^  •  (a,  (t2  ■  a))  is  equal  to  ( |" t'~\  |$|  •  (id$,  t2 ))  •  a. 

This  follows  directly  from  the  fact  that  id§  ■  a  =  a.  Thus  we  have  the  desired  result.  □ 

Lemma  3.4.6  (Substitution  lemma  for  substitutions) 

4b  h  a  :  $  4>;/  h  a :  4b 

h  a  ■  o' :  $ 

Proof.  By  structural  induction  on  the  typing  derivation  of  o  and  using  the  main  substitution  theorem 
for  terms.  □ 

Lemma  3.4.7  (Types  are  well-typed)  If  $  b  t  :  t'  then  either  t'  =  Type  or 
$  b  t' :  s. 

Proof.  By  structural  induction  on  the  typing  derivation  for  t  and  use  of  the  substitution  lemma  in  cases 
where  t'  involves  a  substitution,  as  for  example  in  the  IIElim  case.  □ 

Lemma  3.4.8  (Weakening) 


4>bt:£/  <&'  =  4>,  tj,  t2,  ,  tn  b  <&' wf 

W  t-.f 


Proof.  Simple  application  of  the  substitution  theorem  using  a  =  id,x, 


□ 


53 


Chapter  4 

The  logic  dHOL:  Extension  variables 


In  this  chapter  we  will  present  an  extension  to  the  xHOL  logic  which  is  necessary  in  order  to  support 
manipulation  of  logical  terms  through  the  computational  layer  of  VeriML.  We  will  add  two  new  kinds  of 
variables  in  dHOL:  meta-variables,  which  are  used  so  that  VeriML  can  manipulate  open  logical  terms  in¬ 
habiting  specific  contexts;  and  context  variables,  which  are  necessary  so  that  we  can  manipulate  contexts 
themselves,  as  well  as  open  terms  that  inhabit  any  context  -  through  combination  with  the  meta-variables 
support.  We  refer  to  both  of  these  new  kinds  of  variables  as  extension  variables.  We  will  describe  this  addi¬ 
tion  to  dHOL  in  two  steps  in  the  interests  of  presentation,  introducing  meta-variables  first  in  Section  4.1 
and  then  adding  context  variables  in  Section  4.2.  In  both  cases  we  will  present  the  required  metatheoretic 
proofs  in  detail. 

4.1  /IHOL  with  metavariables 

We  have  mentioned  in  Chapter  2  that  VeriML  works  over  contextual  terms  instead  of  normal  logical 
terms,  because  we  want  to  be  able  to  work  with  open  terms  in  different  contexts.  The  need  for  open 
terms  naturally  arises  even  if  we  ultimately  want  to  produce  closed  proofs  for  closed  propositions.  For 
example,  we  want  to  be  able  to  pattern  match  against  the  body  of  quantified  propositions  like  Vx  :  Nat.P. 
In  this  case,  P  is  an  open  term  even  if  the  original  proposition  was  closed.  Similarly,  if  we  want  to  produce 
a  proof  of  the  closed  proposition  Pl  — >  P2,  we  need  an  open  proof  object  of  the  form  Pl  b?  :  P2.  In  a 
similar  case  in  Section  2.3,  we  used  the  following  notation  for  producing  the  proof  of  P{  — »  P2: 

X 

$  b  P1-*P2 

Using  the  more  precise  notation  which  we  use  in  this  chapter,  that  includes  proof  objects,  we  would  write 
the  same  derivation  as: 

*:(*,  P&Pi) 

$  b  \{Px).X  ■p1^p2 

The  variable  X  that  we  use  here  is  not  a  simple  variable.  It  stands  for  a  proof  object  that  only  makes 
sense  in  the  T,  Px  environment  -  we  should  not  be  allowed  to  use  it  in  an  environment  that  does  not 
include  Pv  It  is  a  meta-variable :  a  special  kind  of  variable  which  is  able  to  ‘capture’  variables  from  the 
current  context  in  a  safe  way,  when  it  is  substituted  by  a  term  t .  The  type  of  this  meta-variable  needs  to 
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Syntax  extensions 


Substitution  application: 


( Logical  terms) 

*  ■■■■=-  \XJa 

t  ■  a 

=  t' 

( Contextual  terms) 

T  ::=[*]  t 

( Meta-contexts ) 

T  ::=  •  |  T,  T 

C Xi/cj')-(T 

=  XjW-v) 

( Meta-substitutions ) 

ftp  ::=  •  |  fg>)  T 

Freshening: 

\tV  and  [af 

11  m  1  1  m 

Binding:  [tj 

n  and  \a\n 

m  L 

ViMnm  = 

L *iMnm  = 

*i/(kl> 

«  = 

• 

K  = 

• 

= 

(M”)>  r*r 

\i  i  ynn  1  1  m 

= 

(kf)>  [t\n 

\L  j  m n  L  J  m 

Figure  4.1:  Extension  of  /iHOL  with  meta-variables:  Syntax  and  Syntactic  Operations 


contain  both  the  information  about  the  expected  environment  where  t  will  make  sense  in  addition  to  the 
type  of  the  term.  Types  of  metavariables  are  therefore  contextual  terms :  a  package  of  a  context  $  together 
with  a  term  t,  which  we  will  write  as  [T]  t  and  denote  as  T  in  the  rest  of  our  development.  The  variable 
X  above  will  therefore  be  typed  as: 

*:[*>  P\]p2 

The  notational  convention  that  we  use  is  that  the  [•]  bracket  notation  associates  as  far  to  the  right  as 
possible,  taking  precedence  over  constructors  of  logical  terms.  An  instantiation  for  the  variable  X  would 
be  a  term  t  with  the  following  typing  derivation: 

$,P1ht:P2 

If  we  define  this  derivation  as  the  typing  judgement  for  the  contextual  term  [T,  P,]  t,  we  can  use  contex¬ 
tual  terms  in  order  to  represent  instantiations  of  meta-variables  too  (instead  of  just  their  types)1.  Thus  an 
instantiation  for  the  variable  X  is  the  contextual  term  [T,  P,  ]  t  with  the  following  typing: 

h[$,  P,]t:[*,Px]P2 

We  use  capital  letters  for  metavariables  in  order  to  differentiate  them  from  normal  variables.  Since  they 
stand  for  contextual  terms,  we  also  occasionally  refer  to  them  as  contextual  variables. 

Let  us  now  see  how  the  /HOL  logic  can  be  extended  in  order  to  properly  account  for  meta-variables, 
enabling  us  to  use  them  inside  logical  terms.  The  extensions  required  to  the  language  we  have  seen  so  far 
are  given  in  Figures  4.1  (syntax  and  syntactic  operations)  and  4.2  (typing  judgements).  The  main  addition 
to  the  logical  terms  is  a  way  to  refer  to  metavariables  X t.  These  come  from  a  new  context  of  meta¬ 
variables  represented  as  T  and  are  instantiated  with  contextual  terms  T  through  meta-substitutions  oy, . 
All  metavariables  are  free,  as  we  do  not  have  binding  constructs  for  metavariables  within  the  logic.  We 
represent  them  using  deBruijn  levels,  similar  to  how  we  represent  normal  logical  variables.  We  have  made 

1.  It  would  be  enough  to  instantiate  variables  with  logical  terms  t,  as  the  context  they  depend  on  will  theoretically  be  evident 
from  the  type  of  the  meta-variable  they  are  supposed  to  instantiate.  This  choice  poses  unnecessary  technical  challenges  so  we  opt 
to  instantiate  metavariables  with  contextual  terms  instead. 
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Th  =  T  T  =  [$x]  t'  'I1;  $  b  a  :  <E7 

- - - MetaVar 

T;  QhXJa-.t'-a 


T;  <Eb  t:t' 


b  T  wf 


- MetaCEmpty 

b  •  wf 


b  T  wf  'Eh  [<E]  t  :  [<E]  5 

- MetaCVar 

h  ('E,  [<E]  t)  wf 


'Eh  T:T' 


'E;  $  h  t  :  t' 
'Eb  [$]  t :  [<E]  t' 


CtxTerm 


'E  h  a^, :  T7 


- MetaSEmpty 

'Eh*:* 


'E  h  <jy  :  'E/  'Eh  T  :T'  ■ 

- - - -  MetaSVar 

'EhK,  T) :  ('E  ,  T  ) 


Figure  4.2:  Extension  of  dHOL  with  meta-variables:  Typing  rules 

this  choice  so  that  future  extensions  to  our  proofs  are  simpler2;  we  will  use  the  name-based  representation 
instead  when  it  simplifies  our  presentation. 

To  use  a  meta-variable  Xi  inside  a  logical  term  t ,  we  need  to  make  sure  that  when  it  gets  substituted 
with  a  contextual  term  T  =  [<E7]  t',  the  resulting  term  t[T  /X~\  will  still  be  properly  typed.  The  variables 
that  t '  contains  need  to  make  sense  in  the  same  context  $  that  is  used  to  type  t.  We  could  therefore  require 
that  the  meta-variable  is  only  used  in  contexts  $  that  exactly  match  <§>' ,  but  this  limits  the  cases  where  we 
can  actually  use  meta-variables.  We  will  opt  for  a  more  general  choice  instead:  we  require  a  mapping 
between  the  variables  that  t '  refers  to  and  terms  that  make  sense  in  the  context  $  where  the  metavariable 
is  used.  This  mapping  is  provided  by  giving  an  explicit  substitution  when  using  the  variable  Xt ,  leading 
to  the  new  form  XJ a  included  in  the  logical  terms  shown  in  Figure  4.1;  the  requirement  that  a  maps 
the  variables  of  context  T7  to  terms  in  the  current  context  is  captured  in  the  corresponding  typing  rule 
MetaVar  of  Figure  4.2.  The  most  common  case  for  a  will  in  fact  be  the  identity  substitution  (where  the 
contexts  $  and  T7  match,  or  <E7  is  a  prefix  of  T),  in  which  case  we  usually  write  Xi  instead  of  Xi /id§. 

Extending  the  operations  of  substitution  application,  freshening  and  binding  is  straightforward;  in 
the  latter  two  cases,  we  need  to  extend  those  operations  to  work  on  substitutions  as  well.  The  original 
typing  judgements  of  dHOL  are  adapted  by  adding  the  new  lE  context.  This  is  ignored  save  for  the  new 

2.  Specifically,  we  are  interested  in  adding  meta-n-variables  to  the  logic  language.  We  can  view  normal  logical  variables  as 
meta-O-variables  and  the  meta-variables  we  add  here  as  meta-l-variables;  similarly,  we  can  view  logical  terms  t  as  meta-O-terms 
and  contextual  terms  T  as  meta- 1-terms;  and  so  on.  We  carry  out  the  same  proofs  for  both  levels,  leading  us  to  believe  that  an 
extension  to  n  levels  by  induction  would  be  a  simple  next  step. 
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t  •  0\j/  —  t' 


s  • 

~ 

s 

C  ■  (7-qj 
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c 

V,  ■  <Jy 

— 

v, 

bi  • 
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h 

•  0\jr 

— 

Kh  ■  ■  aq) 

(T  h) '  a<n 

~ 

(t\  ‘  0\j,)  (t2  ‘  &J) 

(n(h)-A) 

— 

n(T  ■  a^)-{h  ■  (7'e) 

II 

27 

Cvp 

~ 

(T  • a^) =  (a  •  a<tf) 

( conv  tx  t 

2)  '  a'S> 

— 

conv(tx-  oJ)(t2-  crj) 

( refl  t)-aq 

~ 

refl(t-aj) 

(subst  (tk. 

tp)  t)  •  l T-q, 

— 

subst  (tk  ■  a^.tp  •  aj)  (t  ■ 

(< congLam  (t^.t))  ■  ay, 

— 

congLam  (t^  ■  a^.t  ■  aq,) 

(congFora 

U(tk.t))-a^ 

— 

congForall  (tk-  a^.t  ■  aj 

(beta  (tfc.  < 

h)  h)  ‘ 

— 

beta(tk-  (j^.t^  -  aj)(t2- 1 

(XJa)-a^ 

— 

t'  -(a  ■  cr^,)  when  a^.i  = 

e 

II 

b 

e 

•  •  (7^  - 

—  • 

* 

($,  t)  ■  - 

=  $ 

*  ^ 

o  '  °\j,  —  o' 


(o',  f)- 


—  o  •  O-s,,  t  •  ( 7\r 


T-a^  =  r 


([$]f)-o-^  =  [$-o\j,](£ 


O',! 


Figure  4.3:  Extension  of  aHOL  with  meta-variables:  Meta-substitution  application 


MeTAVar  rule.  Well-formedness  conditions  for  the  \F  context  are  similar  to  the  ones  for  <F,  whereas  typing 
for  contextual  terms  \F  h  T  :  T  is  as  suggested  above. 

Substitutions  for  metavariables  are  lists  of  contextual  terms  and  are  denoted  as  o\I; .  We  refer  to  them 
as  metasubstitutions.  Their  typing  rules  in  Figure  4.2  are  similar  to  normal  substitutions.  Of  interest  is 
the  definition  of  meta-substitution  application  t  ■  o\[;,  given  in  Figure  4.3.  Just  as  application  of  normal 
substitutions,  this  is  mostly  a  structural  recursion.  The  interesting  case  is  when  t  =  XJ a.  In  this  case, 
we  extract  the  z-th  contextual  term  T  =  [<F]  l'  out  of  the  metasubstitution  oy, .  t'  is  then  applied  to  a 
substitution  o'  =  a  ■  It  is  important  to  note  that  a '  could  not  simply  be  equal  to  a,  as  the  substitution 
a  itself  could  contain  further  uses  of  metavariables.  Also,  the  $  context  is  not  needed  in  the  operation 
itself,  so  we  have  elided  it  in  the  definition. 

Metatheory 

Since  we  extended  the  logical  terms  with  the  new  construct  XJ  a,  we  need  to  make  sure  that  the  lemmas 
that  we  have  proved  so  far  still  continue  to  hold  and  were  not  rendered  invalid  because  of  the  extension. 
Furthermore,  we  will  state  and  prove  a  new  substitution  lemma,  capturing  the  fact  that  metasubstitution 
application  to  logical  terms  still  yields  well-typed  terms  in  the  new  meta-variables  environment. 

In  order  to  avoid  redoing  the  proofs  for  the  lemmas  we  have  already  proved,  we  follow  an  approach  to¬ 
wards  extending  our  existing  proofs  that  resembles  the  open  recursion  solution  to  the  expression  problem. 
All  our  proofs,  in  their  full  detail  as  published  in  our  Technical  Report  [Stampoulis  and  Shao,  2012b],  are 
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based  on  structural  induction  on  terms  of  a  syntactical  class  or  on  typing  derivations.  Through  the  exten¬ 
sion,  such  induction  principles  are  generalized,  by  adding  some  new  cases  and  possibly  by  adding  mutual 
induction.  For  example,  structural  induction  on  typing  derivations  of  logical  terms  $  b  t  :  t'  is  now 
generalized  to  mutual  induction  on  typing  derivations  of  logical  terms  T;  $  b  t  :  t'  and  of  substitutions 
VF;  $  b  a  :  The  first  part  of  the  mutual  induction  matches  exactly  the  existing  proof,  save  for  the 

addition  of  the  new  case  for  t  =Xi/ a;  this  case  actually  is  what  introduces  the  requirement  to  do  mutual 
induction  on  substitutions  too.  We  did  our  proofs  to  a  level  of  detail  with  enough  individual  lemmas  so 
that  all  our  proofs  do  not  perform  nested  induction  but  utilize  existing  lemmas  instead.  Therefore,  we 
only  need  to  prove  the  new  cases  of  the  generalized  induction  principles  in  order  to  conclude  that  the 
lemmas  still  hold  for  the  extension.  Of  course,  lemma  statements  need  to  be  slightly  altered  to  account 
for  the  extra  environment. 

Lemma  4.1.1  (Extension  of  Lemma  3.4.1)  (Identity  substitutions  are  well-typed) 

T  b  4>  wf  $  =  3>,  tx,  t2,  ■  ■  ■ ,  tn  T  b  &  wf 
T;  &  b  id# :  $ 

Proof.  The  original  proof  was  by  structural  induction  on  4>,  where  no  new  cases  were  added.  The  new 
proof  is  thus  identical  as  before.  □ 

Lemma  4.1.2  (Extension  of  Lemma  3.4.2)  (Interaction  between  freshening  and  substitution  application) 

t  <f  m  a  <f  m  \a\  —  m  o'  <f  m  a  <f  m  \a\  =  m 

r^l  =  Vm')  \a> '  aXni  ~  Kl  m  ’  (<7»  V) 

Proof.  Because  of  the  extension,  structural  induction  on  t  needs  to  be  generalized  to  mutual  induction 
on  the  structure  of  t  and  of  a'.  Part  1  of  the  lemma  is  proved  as  before,  with  the  addition  of  the  following 
extra  case  for  t  =  XJ a  .  We  have: 


n 

/ 

YYl 


\{Xila)-a  ]\=  p ('/(a'-a)]] 

=  XJ\a'.a  l”, 

=  X,/(\aTm-(a’  Vm')) 
=  ([^/c7TJ-(<7’  v) 


(by  definition) 
(by  definition) 

(using  mutual  induction  hypothesis  for  part  2) 

(by  definition) 


The  second  part  of  the  proof  is  proved  similarly,  by  structural  induction  on  a' . 

Lemma  4.1.3  (Extension  of  Lemma  3.4.3)  (Interaction  between  binding  and  substitution  application) 


□ 


1. 


t  <1  m  +  1 


a  m 


\a\  =  m 


2. 


o’  m  +  1 


a  m 


(j  =  m 


I  m  +1 

Proof.  Similar  to  the  above. 


\_a  •  (a,  Vm')\  ” /+i  =  L^'J  1+!  ’ a 


□ 
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Lemma  4.1.4  (Extension  of  Lemma  3.4.4)  (Substitutions  are  associative j 

1.  (t  •  a)  •  o'  =  t  ■  (o  •  a') 

2.  (ct-j  •  a)  ■  o’  =  ol  ■  (a  ■  a1) 

Proof.  Similar  to  the  above.  □ 


Theorem  4.1.5  (Extension  of  Theorem  3.4.5)  (Substitution) 

'P;$/|-C7:$  'P;  &  b  a  :  $  $"  h  o'  : 

1. -  2. - 

ty-,  &  \~  t  ■  o  :  t'  ■  o  'P;  4>/;  h  (7  •  o' :  $ 

Proof.  We  have  proved  the  second  part  of  the  lemma  already  as  Lemma  3.4.6.  For  the  first  part,  we  need 
to  account  for  the  new  typing  rule. 

Case  MetaVar. 

/  'P.i  =  T  T  =  [<P0]  t0  'P;  $  I-  o-0  :  <P0 

\  'P;  ^\-XJa0:t0-a0 

Applying  the  second  part  of  the  lemma  for  o  =  a0  and  o'  =  a  we  get: 

'P;<P/b<70V:<P0. 

By  applying  the  same  typing  rule  for  t  =  XJ(o0  ■  a)  we  get: 

'P;  0  V) :  t0  •  (u0  •  cr'). 

By  associativity  of  substitution  application,  this  is  the  desired  result.  □ 


Lemma  4.1.6  (Meta-context  weakening) 

4/;4>b  t  :  t'  'P;4>b<r:4>/ 

'P  h  r  :  T 

4. - 

$  T,  ...  T  FT  -T 

Proof.  Trivial  by  structural  induction  on  the  typing  derivations. 

Lemma  4.1.7  (Extension  of  Lemma  3.4.7)  (Types  are  well-typed) 
Ifx P;  <P  b  t :  t'  then  either  t'  =  Type  or ' P;  4>  b  t' :  s. 

Proof.  By  induction  on  typing  for  t,  as  before. 


4/  b  4>  wf 
,Tn\-$wf 


□ 


Case  MetaVar. 

/  'P.z  —  T  T  =  [4b]  t'  41;  $  b  o  :  4b  \ 

V  'P;  S^XJo-.t'-o  ) 

By  inversion  of  well-formedness  for  4/  and  meta-context  weakening,  we  get: 
'P  b  'P.z  :  [4>']  s 
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By  typing  inversion  we  get: 

'I';  $'b  t':s. 

By  application  of  the  substitution  theorem  for  t'  and  a  we  get  \B;  $  b  t' -a  :  s,  which  is  the  desired  result. 

□ 

Lemma  4.1.8  (Extension  of  Lemma  3.4.8)  (Weakening) 

\B;  $  b  t  :  f  =  $,  tv  t2,  •  •  • ,  tn  \B  b  wf 

1. - 

T;  $'bt  :f 

\B;  $  b  a  :  $  =  <B,  tx,  t2,  ••• ,  tn  \B  b  <BX  wf 

2. - 

'B;  $'  b  a  :  $" 

Proof.  The  new  case  for  the  first  part  is  proved  similarly  to  the  above.  The  proof  of  the  second  part  is 
entirely  similar  to  the  first  part  (use  substitution  theorem  for  the  identity  substitution).  □ 

We  have  now  extended  all  the  lemmas  that  we  had  proved  for  the  original  version  of  dHOL.  We  will  now 
proceed  to  prove  a  new  theorem  about  application  of  meta-substitutions,  similar  to  the  normal  substitu¬ 
tion  theorem  4.1.5.  We  first  need  some  important  auxiliary  lemmas. 

Lemma  4.1.9  (Interaction  of  freshen  and  metasubstitution  application) 

'B  b  aq, :  'B/  \B  b  :  'B/ 

L  Z\a]l.a^  =  \a.a^m 

Proof.  The  first  part  is  proved  by  induction  on  t.  The  interesting  case  is  the  t  =XJ a  case,  where  we 
have  the  following. 


\xm 


n 

m 


<r*  =  (xilW  VJ'a* 

=  -<r9) 

=  v^-i  •  k  • 

=  t' Vm 

=  \Xi/° 


(based  on  part  2) 
(assuming  a^.i  =  [<B]  f) 
(since  f  does  not  include  bound  variables) 


The  second  part  is  proved  trivially  using  induction  on  a. 


Lemma  4.1.10  (Interaction  of  bind  and  metasubstitution  application) 


'B  b  :  'B/ 


\B  b  :  'B/ 


L^J 


=  It 


□ 
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Proof.  Similar  to  the  above. 


□ 


Lemma  4.1.11  (Substitution  and  metasubstitution  application  distribute) 

1-  (t  ■  a)  ■  ay  =  (t  ■  ay)  ■  (a  ■  ay) 

2.  (a  ■  a')  -ay  =  (a-  ay)  ■  (a'  ■  ay) 

Proof.  Similar  to  the  above.  □ 

Lemma  4.1.12  (Application  of  metasubstitution  to  identity  substitution) 
idy  ■  ay  =  idy.ay 

Proof.  By  induction  on  <P.  □ 

Theorem  4.1.13  (Meta-substitution  application) 

\P;  <P  b  t  :  t'  'P/  h  ay  :  \P  \P;  $  h  a  :  &  'P/  h  (7,j  :  $  \P  h  $  wf  'P/  h  ay  :  'P 

1. -  2. -  3. - 

'P';  $  •  ay  b  t  ■  ay  :  t'  ■  ay  'P';  $  •  ay  b  a  ■  ay  :  <P'  •  ay  'P'  b  §-aywf 

\P  b  T :  T'  \P/  b  ay  :  'P 
'P'  b  T  ■  ay  :  V  ■  ay 

Proof.  All  parts  proceed  by  structural  induction  on  the  typing  derivations.  Here  we  will  give  some 
representative  cases. 

Case  IIElim. 

/  $  b  t{  :  II (t).t'  $  b  t2  :  t  ^ 

\  $  b  tj  t2  :  \t'~\  |$|  •  (idy,  t2)  I 

By  induction  hypothesis  for  tx  we  get: 

'P';  $  •  ay  b  ti  ■  ay  :  II(t  •  ay).(t'  ■  ay). 

By  induction  hypothesis  for  t2  we  get: 

'P/;  $-ay\~t2-ay\t-  ay. 

By  application  of  the  same  typing  rule  we  get: 

'P';  ^'^b  (tx  t2)  ■ ay :  \t'  ■  ay~\  ^  •  (idy,  t2  ■  ay). 

We  need  to  prove  that  ( [ t'~\  ^  •  (idy,  t2))  ■  ay  =  \t'  ■  ay)  ^  •  ( idy. ^ ,  t2  •  o^). 


(  1  |$|  ■  (idy,  t2))  ■  ay  =  (  |~t  ]  |$|  •  Ug;)  •  ((idy,  t2)  ■  ay) 

=  ( \t  '  |$|)  •  ((idy,  t2)  ■  ay) 

—  ( \  t  |$[)  ‘  (idy  •  ay,  t2  •  ay) 

~  ‘  |$|  ‘  (id$.cr9>t 2  ’  aty) 


(by  Lemma  4.1.11) 
(by  Lemma  4.1.9) 
(by  definition) 
(by  Lemma  4.1.12) 
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Case  MetaVar. 

/  T.z  =  T  T  =  [4b]  t'  'I1;  $  b  a  :  4b 
\  'L;  QhXi/a-.t'-a 

Assuming  that  a^.i  =  [4>"]  £,  we  need  to  show  that  4b;  $  •  u\j,  h  t  ■  (a  •  o :  (£;  •  a)  • 

Equivalently  from  Lemma  4. 1 . 1 1  we  can  instead  show 
'L/;  $  •  h  t  ■  (a  ■  axV) :  (t'  ■  axV)  ■  ( a  ■  cr^) 

Using  the  second  part  of  the  lemma  for  a  we  get:  4b;  $  •  h  a  ■  o\j, :  4b  ■  a^, 

Furthermore  we  have  that  4b  h  a^.i  :  T.z  •  a^. 

From  hypothesis  we  have  that  4/.z  =  [4b]  l' 

Thus  the  above  typing  judgement  is  rewritten  as  4b  b  a^.i  :  [4b  •  t'  ■ 

By  inversion  we  get  that  4>"  =  4b  •  a^,  thus  a^.i  =  [4b  •  a^\  t;  and  that 
4b;  T'^hi:A  o> 

Now  we  use  the  main  substitution  theorem  4.1.5  for  t  and  a  ■  and  get: 

V;  4>  •  ay  b  t  ■  (a  ■  <JxV) :  (t'  ■  o\j>)  ■  (a  ■  a y) 

Case  SubstVar. 

$  b  a  :  $bt:d'ff\ 

^bcr,  t  :  (4>/,  t')  ) 

By  induction  hypothesis  and  use  of  part  1  we  get: 

'F/;  $  •  Py  b  a  •  cry  :  4>'  ■ 

4b; 

By  use  of  Lemma  4. 1. 1 1  in  the  typing  for  t  ■  we  get  that: 

4b;  <f>  •  o\j,  b  r  •  o\j, :  ( t 1  ■  o^)  ■  (a  ■  cr^) 

By  use  of  the  same  typing  rule  we  get: 

T';  $  •  b  (a  ■  t-  a^) :  ($'  •  (JxV,  t'  ■  axll)  □ 

4.2  /IHOL  with  extension  variables 

Most  functions  in  VeriML  work  with  logical  terms  that  live  in  an  arbitrary  context.  This  is  for  example 
true  for  automated  provers  such  as  the  tautology  prover  presented  in  Section  2.3,  which  need  to  use 
recursion  to  prove  propositions  in  extended  contexts.  Thus,  even  if  the  original  context  is  closed,  recursive 
calls  work  over  terms  living  in  extensions  of  the  context;  and  the  prover  needs  to  handle  all  such  extensions 
-  it  needs  to  be  able  to  handle  all  possible  contexts.  The  metavariables  that  we  have  seen  so  far  do  not  allow 
this  possibility,  as  they  depend  on  a  fully-specified  $  context.  In  this  section  we  will  see  a  further  extension 
of  aHOL  with  parametric  contexts.  Contexts  can  include  context  variables  that  can  be  instantiated  with  an 
arbitrary  context.  We  can  see  context  variables  as  placeholders  for  applying  the  weakening  lemma.  Thus 
this  extension  internalizes  the  weakening  lemma  within  the  aHOL  calculus,  just  as  the  extension  with 
metavariables  internalizes  the  substitution  theorem.  We  denote  context  variables  with  lowercase  letters, 
e.g.  <f>,  in  order  to  differentiate  from  the  $  context. 

Let  us  sketch  an  example  of  the  use  of  parametric  contexts.  Consider  the  case  where  we  want  to 
produce  a  proof  of  x  >  0  — >  x  >  I  in  some  unspecified  context  4>.  This  context  needs  to  include  a 
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definition  of  %  as  a  natural  number  in  order  for  the  proposition  to  make  sense.  We  can  assume  that  we 
have  a  metavariable  X  standing  for  a  proof  with  the  following  context  and  type: 

X  :[x  :  Nat,  <f>,  h  :  x  >  0]  %  >  1 
we  can  produce  a  proof  for  [x  :  Nat,  <^>]  x  >  0  — »  x  >  1  with: 

X  :  \x  :  Nat,  <f>,  h  :  x  >  0]  %  >  1 
%  :  Nat,  cf>  b  (Ah  :  x  >  0.X) :  x  >  0  — *■  x  >  1 

The  context  variable  <f>  can  be  instantiated  with  an  arbitrary  context,  which  must  be  well-formed  under 
the  initial  %  :  Nat,  context.  We  capture  this  information  into  the  type  of  &  as  follows: 

<f> :  [x  :  Nat ]  ctx 

A  possible  instantiation  of  (])  is  <f>  =  \h  :  x  >  5],  By  applying  the  substitution  of  (f)  for  this  instantiation 
we  get  the  following  derivation: 

X  :  [x  :  Nat,  h  :  x  >  5,  //  :  %  >  0]  x  >  1 
x  :  Nat,  h  :x>  5  b  (Ah' :  x  >  0.A) :  x  >  0  — *■  x  >  1 

As  is  evident,  the  substitution  of  a  context  variable  for  a  specific  context  might  involve  a  series  of  a- 
renamings  in  the  context  and  terms,  as  we  did  here  so  that  the  newly-introduced  h  variable  does  not  clash 
with  the  already  existing  h  variable. 

We  will  now  cover  the  extensions  required  to  dHOL  as  presented  so  far  in  order  to  account  properly 
for  parametric  contexts.  The  main  ideas  of  the  extension  are  the  following: 

1.  Both  context  variables  and  meta-variables  should  be  typed  through  the  same  environment  and 
should  be  instantiated  through  the  same  substitutions,  instead  of  having  separate  environments 
and  substitutions  for  context-  and  meta-variables. 

2.  The  deBruijn  levels  used  for  normal  free  variables  should  be  generalized  to  parametric  deBruijn 
levels :  instead  of  being  constant  numbers  they  should  be  sums  involving  variables  \(f>\  standing  for 
the  length  of  as-yet-unspecified  contexts. 

We  have  arrived  at  an  extension  of  dHOL  that  follows  these  ideas  after  working  out  the  proofs  for  a  variety 
of  alternative  ways  to  support  parametric  contexts.  The  solution  that  we  present  here  is  characterized  both 
by  clarity  in  the  definitions  and  the  lemma  statements  as  well  as  by  conceptually  simple  proofs  that  can 
be  carried  out  using  structural  recursion.  Intuitively,  the  main  reason  is  that  parametric  deBruijn  levels 
allow  for  a  clean  way  to  perform  the  necessary  or-renamings  when  instantiating  a  parametric  context  with 
a  concrete  context,  by  simply  substituting  the  length  variables  for  the  concrete  length.  Other  solutions  - 
e.g.  keeping  free  variables  as  normal  deBruijn  levels  and  shifting  them  up  when  a  parametric  context  is 
instantiated  -  require  extra  knowledge  about  the  initial  parametric  context  upon  instantiation,  destroying 
the  property  that  meta-substitution  application  is  structurally  recursive.  The  justification  for  the  first 
key  idea  noted  above  is  technically  more  subtle:  by  separating  meta-variables  from  context  variables  into 
different  contexts,  the  relative  order  of  their  introduction  is  lost.  This  leads  to  complications  when  a 
meta-variable  depends  on  a  parametric  context  which  depends  on  another  meta-variable  itself  and  requires 
various  side-conditions  to  the  statements  of  lemmas  that  add  significant  technical  complexity. 
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( Logical  terms ) 

t 

:=  s\  c  |  vL  |  bi  |  A(tj).t2  \t1t2  | 

nw 

|  cowu  £j  £2  |  subst  ((tk).tP)  t  |  refl  t  \ 

|  congForall  ((tk).t)  \  beta  {(tk) 
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( Parametric  deBruijn  levels) 

L 

:=  0  |  Z.+  1  |  E  +  |^-| 

( Contexts ) 

<P 

:=•••  |$,  (f)i 

(, Substitutions ) 

a 

H 

Jil 

( Extension  contexts ) 

'P 

:=  •  |  'P,  K 

*  ( Extension  terms) 

T 

:=  [<P]  £  |  [$]$' 

( Extension  types) 

K 

:=  [<p]  £  |  [<p]  ctx 

( Extension  substitutions) 

:=  •  |  T 

Figure  4.4:  Extension  of  xHOL  with  parametric  contexts:  Syntax 


Substitution  length:  |<r|  =  L 

M  =  0 

| a,  t\  =  |cr|  4-  1 

la>  id(^>j)|  =  H  +  |^| 

Substitution  access:  a  .L  —  t 

(a,  t).L  =  £when|<r|=Z, 

(a,  t).L  =  a.L  otherwise 

(a,  i d(<f>j)).L  =  a.L 

Substitution  application: 

£  ■  a  —  t' 

vL  ■  a  =  a.L 

Identity  substitution: 
id§  =  a 

id,  =  • 


Context  length:  \a |  =  L 

M  =  0 
l<M  =  i$i+i 
\*><f>i\  =  l$l  +  l^'l 

Context  access:  <IkL  =  t 

(<P,  t).L  =  £  when  |<P|  =  L 
(<P,  t).L  =  <P.Z,  otherwise 
(*,&)•£  = 

Substitution  application: 
a'  ■  a  —  a" 

(a\  id(<^))  •  a  =  a'  ■  a,  id(<^) 

Partial  identity  substitution: 
zc^[$]  <p  =  ° 


• 

II 

^[$]  J 

•+ 

& 

£ 

& 

rs 

ii 

ii 

>o 

Cl. 

Figure  4.5:  Extension  of  xHOL  with  parametric  contexts:  Syntactic  Operations  (Length  and  access  of 
substitutions  and  contexts;  Substitution  application;  Identity  substitution  and  partial  identity  substitu¬ 
tion) 


64 


Variable  limits:  t  <f  L 


Level  comparison:  L  <  L' 

L  <  L!  +  1  when  L  =  L'  or  L  <  l! 

L  <  L'  +  \cf)  •  |  when  L  =  ll  or  L  <  Ll 


s  <f  L 
c<f  L 
vL<fL' 

bt  <f  L 

{Kh\h)  <f  L 
tt  t2  </  L 


L<L' 

tt<f  L  A  t2  <f  L 
tx<f  LA  t2  <f  L 


Variable  limits:  a  <f  L 

•  <f  L 

a,  t  <f  L  -<=  o  <f  L  Kt  L 
a ,  id(^S  ■)  <f  L  -<=  a  <f  L  A  L  =  Ll  +  \cf>t |  H - 


Figure  4.6:  Extension  of  7HOL  with  parametric  contexts:  Variable  limits 


Freshening  (terms):  [t]”  =  t' 

\hVL  =  vL 
\hVL  =  h 

Binding  (terms):  \t  J”  =  t' 

=  when  L  =  Ll  +  1 
\yLi J”  =  otherwise 


Freshening  (subst.):  [cj]”  =  a' 

M2  =  • 

K*12  =  M12.M2 

Binding  (subst.):  [uj”  =  a7 

M2  =  • 

k>  t\nL  =  H2.M2 
[cr,  id(^,)J2  =  kJ2>  id(&) 


Figure  4.7:  Extension  of  dHOL  with  parametric  contexts: 

Syntactic  Operations  (Freshening  and  binding) 

Environment  subsumption: 

Substitution  subsumption: 

in 

$  C  $ 

a  C  a 

$  C  $/,  t  -<=  $  C 

in 

it 

in 

®Q&,<f>i  4=  $  C 

in 

\ 

JX 

1> 

in 

Figure  4.8:  Extension  of  dHOL  with  parametric  contexts:  Subsumption 
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\E  bs  $  wf 


lEb^wf  'I1;  $  b  t :  s  T  h  <E  wf  'I1  .i  =  [<E]ct% 

- CtxEmpty  - CtxVar  - CtxCVar 

\Eb«wf  \E  b  ($,  £)wf  \E  b  (<E,  cj)  ■)  wf 


T;  $  h  a  :  $' 


- SubstEmpty  - - — - - SubstVar 

\E;  <E  b  •  :  •  \E;  <E  b  (a,  t) :  (3>  ,  t  ) 


'E;  $  b  a  :  <E7  \E.z  =  [ 4b]  ctx  (4b,  <b;)  C  $ 

- — - - - — - SUBSTCVAR 

'E;  id(<^)):($  ,  <j>i) 


Figure  4.9:  Extension  of  /HOL  with  parametric  contexts:  Typing 

We  present  the  extension  of  /HOL  in  a  series  of  figures:  Figure  4.4  gives  the  extension  to  the  syntax; 
Figures  4.5  through  4.7  give  the  syntactic  operations;  Figure  4.8  defines  the  new  relation  of  subsumption 
for  contexts  and  substitutions;  Figures  4.9  and  4.10  give  the  new  typing  rules;  and  Figure  4.11  gives  the 
new  syntactic  operation  of  extension  substitution  application.  We  will  now  describe  these  in  more  detail. 

First  of  all,  instead  of  having  just  metavariables  Xt  as  in  the  previous  section,  we  now  also  have  context 
variables  <j)t.  These  are  free  variables  coming  from  the  same  context  as  metavariables  \E.  We  refer  to  both 
metavariables  and  context  variables  as  extension  variables  and  to  the  context  'E  as  the  extension  context. 
Note  that  even  though  we  use  different  notation  for  the  two  kinds  of  variables  this  is  mostly  a  presenta¬ 
tion  convenience;  we  use  Vt  to  mean  either  kind.  Extension  variables  are  typed  through  extension  types 
-  which  in  the  case  of  metavariables  are  normal  contextual  terms.  Context  variables  stand  for  contexts 
that  assume  a  given  context  prefix  <E,  as  in  the  case  of  the  informal  example  of  &  above.  We  write  their 
type  as  [<E]  ctx,  specifying  the  prefix  they  assume  $  and  the  fact  that  they  stand  for  contexts.  The  instan¬ 
tiations  of  extension  variables  are  extension  terms  T,  lists  of  which  form  extension  substitutions  denoted 
as  aq,.  In  the  case  of  metavariables,  an  instantiation  is  a  contextual  term  [<E]  t  as  we  saw  it  in  the  previous 
section,  its  type  matching  the  contextual  type  [<E]  t'  (rule  ExtCtxTerm  in  in  Figure  4.10).  In  the  case  of 
a  context  variable  (f>i  :  [T]  ctx  an  instantiation  a  context  T'  that  extends  the  prefix  $  (rule  ExTCTXlNST  in 
Figure  4.10).  We  denote  partial  contexts  such  as  (b'  as  [<E]  T7  repeating  the  information  about  $  just  as  we 
did  for  instantiations  of  metavariables. 

In  order  to  be  able  to  use  context  parameters,  we  extend  the  contexts  $  in  Figure  4.4  so  that  they 
can  mention  such  variables.  Well-formedness  for  contexts  is  similarly  extended  in  Figure  4.9  with  the 
rule  CtxCVar.  Notice  that  we  are  only  allowed  to  use  a  context  variable  when  its  prefix  exactly  matches 
the  current  context;  this  is  unlike  metavariables  where  we  allow  them  to  be  used  in  different  contexts  by 
specifying  a  substitution.  This  was  guided  by  practical  reasons,  as  we  have  not  found  cases  where  the  extra 
flexibility  of  being  able  to  provide  a  substitution  is  needed;  still,  it  might  be  a  useful  addition  in  the  future. 

As  described  earlier,  free  logical  variables  are  now  indexed  by  parametric  deBruijn  levels  L  instead 
of  natural  numbers.  This  is  reflected  in  the  new  syntax  for  logical  terms  which  includes  the  form  vL 
instead  of  vt  in  Figure  4.4.  The  new  syntactic  class  of  parametric  deBruijn  levels  represents  the  number  of 
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'E;  $bt  :t' 


c:t  e£ 
'I1;  $  bv  c  :  t 


Constant 


$.L  =  t 
\E;  <E  b  vL:t 


(s,s')  E  A 
'I1;  $  b  s  :  s' 


\E;  <E  b  ^  :  s  'E;  $,  T  b  ft2l|^|  :  s'  ( s,s',s")eK 
T;  $b Ii{tx).t2:s" 


IIType 


V;$\-h:s  'E;  $,  'E;  $  b  n(fj).  |/J  |$|+1  :  «' 

Sb^)^:1^).  |/J|*|+i 


niNTRO 


’E;$bt1:n(t).t'  'E;$bt2:£  V.i  =  T  T  =  [$']  t' 

- — — - IIELIM  _  _ MftaVar 

$  b  t2  :  [l  ]  |$|  •  (id$,  t2)  \E;  $  \~  XJa  :  t'  ■  o 

b  T  wf 

b  \E  wf  \E  b  <E  wf  b  \E  wf  'I'  b  [<E]  t :  [$]  s 

- ExtCEmpty  - ExtCMeta  - EXTCCTX 

b  •  wf  b  (\E,  [4>]  ctx)  wf  b(\E,  [<E]t)wf 

Tb  T:K 


'E;  <Eb  t  :  t' 
'Eb  [$]  t  :  [<E]  t' 


ExtCtxTerm 


\E  b  <E,  <tb  wf 
\E  b  [<E]  3b :  [<E]  ctx 


ExtCtxInst 


\E  b  <jq, :  'E/ 


\E  b  •  :  < 


ExtSEmpty 


\E  b  :  'E/  \E  b  T  :K  •  a^, 
'EbK,  K) 


ExtSVar 


Figure  4.10:  Extension  of  bHOL  with  parametric  contexts:  Typing  (continued) 
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L-  (Jq, 

O-Gq, 

(L  +  1)  •  (Jq, 

*  (^+1^,1)-^ 


t  •  (Jq, 

*  VL'°^ 

{Xilo)-Oq/ 
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*  (<r,  id(^))-a* 


•'  (Jq, 

($>  O'0* 

*  ($,&)•  <7* 


T  ■  CFq, 

([$]  t)-aq, 

([*]  &)  ■ 
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0 

(L  ■  (Jq,)  +  1 
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t  -  (a  ■  <jq,)  when  Gq,.i  =  [_]  t 


(J  •  (Jq,,  t  •  (Jq, 
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$  •  (Jq, ,  t  •  (Jq, 

$  •  (jq,,  &  when  <jq,.i  =  [_] 


[$  •  a*]  (t  •  a*) 
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[$  •  (Jq,\  (t  ■  (Jq,) 
[$  •  <T,j,]  CtX 


/  T  / 

a' V  '  °"^r>  -*  aq. 


Figure  4.11:  Extension  of  /HOL  with  parametric  contexts:  Extension  substitution  application 
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variables  from  the  current  context  that  we  have  to  skip  over  in  order  to  reach  the  variable  we  are  referring 
to.  When  the  current  context  mentions  a  context  variable  ^  ,  we  need  to  skip  over  an  unspecified  number 
of  variables  -  or  rather,  as  many  variables  as  the  length  of  the  instantiation  of  <f>  • .  We  denote  this  length  as 
\<j>i\.  Thus,  instead  of  numbers,  levels  can  be  seen  as  first-order  polynomials  over  the  |<^>-|  variables.  More 
precisely,  they  are  polynomials  that  only  use  noncommutative  addition  that  we  denote  as  +,  reflecting 
the  fact  that  contexts  are  ordered.  It  is  easy  to  see  that  rearranging  the  uses  of  \cf>t  \  variables  inside  level 
polynomials  we  would  lose  the  connection  to  the  context  they  refer  to. 

Substitutions  are  extended  similarly  in  Figure  4.4  to  account  for  context  variables,  using  the  place¬ 
holder  id(<^>-)  to  stand  for  the  identity  substitution  once  St  gets  instantiated.  Notice  that  since  dp  is 
instantiated  with  a  partial  context  [<£]  the  identity  substitution  expanded  in  the  place  of  id(d>;)  will 
similarly  be  a  partial  identity  substitution,  starting  with  the  variable  coming  after  $.  We  define  this  as  a  new 
syntactic  operation  in  Figure  4.5.  The  new  typing  rule  for  substitutions  SubstCVar  given  in  Figure  4.9 
requires  that  we  can  only  use  the  identity  substitution  placeholder  for  <j)l  if  the  current  context  includes 
<j)r  We  make  this  notion  of  inclusion  precise  through  the  relation  of  context  subsumption,  formalized  in 
Figure  4.8,  where  it  is  also  defined  for  substitutions  so  that  it  can  be  used  in  some  lemma  statements. 

The  change  to  parametric  levels  immediately  changes  many  aspects  of  the  definition  of  zHOL:  for 
example,  accessing  the  L-th  element  of  a  context  or  a  substitution  is  not  directly  intuitively  clear  anymore, 
as  L  is  more  than  a  number  and  contexts  or  substitutions  are  more  than  lists  of  terms.  We  have  adapted 
all  such  operations,  including  relations  such  as  level  comparisons  (e.g.  L  <  L')  and  operations  such  as  level 
addition  (e.g.  L+L'  =  L").  We  only  give  some  of  these  here:  substitution  and  context  length  and  accessing 
operations  in  Figure  4.5;  level  comparison  and  variable  limits  in  Figure  4.6;  and  freshening  and  binding  in 
Figure  4.7. 

Last,  the  most  important  new  addition  to  the  language  is  the  operation  of  applying  an  extension 
substitution  cr^,  given  in  Figure  4.11  and  especially  the  case  for  instantiating  a  context  variable.  To  see 
how  this  works,  consider  the  following  example:  we  have  the  context  variable  cf>0  :  [x  :  Nat ]  ctx  and  the 
contextual  term: 

T  =  [x  :  Nat,  (f>0,  y  :  Nat\plus  x  y 
represented  as  T  =  [Nat,  cf>0,  Nat\plus  v0  |. 

We  instantiate  S0  through  the  extension  substitution: 

=  ( <f>0  >->  [x  :  Nat ]  y  :  Nat,  z  :  Nat ) 
represented  as  =  (  [Nat\  Nat,  Nat ).  The  steps  are  as  follows: 

([Nat,  <f>0,  Nat] plus  v0  zq+i^)  •  =  [(Nat,  (f>0,  Nat )  •  o^]  (plus  v0  ^i+|^0|)  •  oy, 

=  [Nat,  Nat,  Nat,  Nat]  (plus  v0  v •  oy, 

=  [Nat,  Nat,  Nat,  Nat]plus  v0  v\+{\cf>a[a^) 

=  [Nat,  Nat,  Nat,  Nat]  plus  vQ  v1_j_2 
=  [Nat,  Nat,  Nat,  Nat]  plus  v0  v3 

Though  not  shown  in  the  example,  identity  substitution  placeholders  id (cf>t)  are  expanded  to  identity 
substitutions,  similarly  to  how  contexts  are  expanded  in  place  of  cf>i  variables. 
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Metatheory 

We  will  now  extend  the  metatheoretic  results  we  have  for  7.HOL  to  account  for  the  additions  and  adjust¬ 
ments  presented  here.  The  auxiliary  lemmas  that  we  proved  in  the  previous  section  are  simple  to  extend 
using  the  proof  techniques  we  have  shown.  We  will  rather  focus  on  auxiliary  lemmas  whose  proofs  are 
rendered  interesting  because  of  the  new  additions,  and  also  on  covering  the  new  cases  for  the  main  substi¬ 
tution  theorems. 

Lemma  4.2.1  (Identity  substitution  leaves  terms  unchanged) 

t<f  L  |$|  =  Z.  a  <f  L  |$|  =  Z. 

1. -  2. - 

t  ■  id§  =  t  a  ■  id§  =  a 

Proof.  Part  1  is  proved  by  induction  on  t  </"  L.  The  interesting  case  is  zy ,  with  L'  <  L.  In  this  case  we 
have  to  prove  id^.l!  —  zy.  This  is  done  by  induction  on  L'  <  L. 

When  L  =  L'  +  1  we  have  by  inversion  of  |T|  =  L  that  T  =  t  and  [T7  =  L' .  Thus  id§  =  id $/,  zy  and 
hence  the  desired  result. 

When  L  =  l!  +  |  cf>t  | ,  similarly. 

When  L  =  L*  +  1  and  l!  <  L*,  we  have  that  $  =  4>*,  t  and  |4>*|  =  L*.  By  (inner)  induction  hypothesis  we 
get  that  id^.L'  =  zy.  From  this  we  get  directly  that  id^.L'  =  zy. 

When  L  =  L*  +  |<^>-|  and  l!  <  L*,  entirely  as  the  previous  case. 

Part  2  is  trivial  to  prove  by  induction  and  use  of  part  1  in  cases  a  =  •  or  a  =  a',  t.  In  the  case  a  = 
a' ,  id ((f) i)  we  have:  o'  <■■  L  thus  by  induction  a'  ■  id§  =  o' ,  and  furthermore  (a)  id (<^>-))  •  id§  =  a.  □ 

Theorem  4.2.2  (Extension  of  Theorem  4.1.5)  (Substitution) 

T;  $  b  t :  t'  T;  $'  h  a  :  $  T;  $'  h  a  :  $  T;  $"  h  a' :  $' 

1. -  2. - 

T;  h  £  •  n  :  t'  ■  a  T;  4>//  h  a  ■  o' :  $ 

Proof.  Part  1  is  identical  as  before;  all  the  needed  lemmas  are  trivial  to  adjust,  so  the  new  form  of  indexes 
does  not  change  the  proof  at  all.  Similarly  for  part  2,  save  for  extending  the  previous  proof  by  the  new 
case  for  substitutions. 

Case  SubstCVar. 

/T;  <I>/  b  a  :  4>0  T.z  =  [4>0]  c£%  (4>0,  ^)C$'\ 

\  T;  $'l-(a,  id(<^)):($0,  <f>0  ) 

By  induction  hypothesis  for  a,  we  get:  T;  <&"  h  a  ■  o' :  4>0. 

We  need  to  prove  that  (<3>0,  <f>t)  C  <&" . 

By  induction  on  (4>0,  St)  C  <l>'  and  repeated  inversions  of  the  typing  of  o’  we  arrive  at  a  a"  C  o7  such 
that: 

T;  h  a"  :  $0,  <f>l 

By  inversion  of  this  we  get  that  (4>0,  d>;)  C  T". 

Thus,  using  the  same  typing  rule,  we  get: 

T;  $7/  h  (<r  •  n^id^)) :  (4>0,  </q)>  which  is  the  desired.  □ 
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Lemma  4.2.3  (Interaction  of  extensions  substitution  and  element  access) 

1.  (a.L)  ■  =  (0  ■  (Jqf-L  ■  0^ 

2.  ($.1)  •  0^  =  ($  •  a^).L  •  o\j, 

Proof.  By  induction  on  L  and  taking  into  account  the  implicit  assumption  that  Z,<|a|orZ,<|$|.  □ 

Lemma  4.2.4  (Extension  of  Lemma  4.1.11)  (Substitution  and  extension  substitution  application  distribute) 

1.  (t  ■  0)  ■  =  (t  ■  a^)  ■  (0  ■  0^ ) 

2.  (0  ■  a')  ■  aq  =  (0  ■  0 •  (a'  ■  0^) 

Proof.  Part  1  is  identical  as  before.  Part  2  is  trivial  to  prove  for  the  new  case  of  0.  □ 

Lemma  4.2.5  (Extension  substitutions  are  associative) 

1.  (L  ■  0*)  ■  a'y  =  L  ■  (0*  ■  a'9) 

2.  (t  ■  0*)  ■  a'y  =  t  ■  (a*  •  0^,) 

3.  ($  •  <r*)  •  =  $  ■  (0*  ■  af) 

4.  =  (0*  •  0 

5.  (T  ■  ay)  -a^  =  T  ■  (0^  ■ 

6.  {K-a^)-a'^=K-{a^-a^) 

7.  (T  •  <T9)  ■  ^  =  'P  •  (<Ty  ■  Oy) 

Proof. 

Part  1  By  induction  on  L.  The  interesting  case  is  L 
(L  ■  a9)  ■  o'y  =  {if  ■  Oy)  ■  Oy  +  |$'|  •  (7^ 

=  (L'  -a^)  + 

=  L'  •  (0*  •t4)  +  |$/-  0^| 

This  is  the  desired,  since  (0^  •  v'^f.i  =  [<P  •  0^]  •  0^ 

Part  2  By  induction  on  t.  The  interesting  case  is  t  =  XJ a .  The  left-hand-side  is  then  equal  to: 

(<ryi  ■  (c  •  <ry))  •  0^  =  (£  •  (0  •  ay))  ■  (t'xV  (assuming  a^.i  =  [$]  t) 

=  f  •  <4)  •  ((<?  ■  °\p)  ■  (Ty)  (through  Lemma  4.2.4) 

=  (t  ■  <4)  ’  (<r  ■  •  a*))  (through  part  4) 

The  right-hand  side  is  written  as: 

{XJa)  •  (0*  •  o'y)  =  ((<7*  •  <Ty).i)  ■  (0  •  (a9  •  0^)) 

=  ((0«-*)-0*)-(0-(0*-0*)) 

=(*  •  <4)  •  •  K- •  O) 


=  l!  +  cf>  • .  In  that  case  we  have: 

(assuming  0^.2  =  [<P]  $  ) 

(by  induction  hypothesis) 
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Part  3  By  induction  on  4>.  When  $  =  4>,  (f>t  and  assuming  o\[;.z  =  [4>]  4>7  we  have  that  the  left-hand  side 
is  equal  to: 


(4>  •  ay)  ■  (Ty,  ■  a'y  =  $  •  (o\j  •  a'y),  &  ■  a'y  (by  induction  hypothesis) 

Also,  we  have  that  (u^  •  u^).z  =  [4>  •  a'^\  4b  •  3. 

The  right -hand-side  is  also  equal  to  $  •  (^V^)’  $/-C74- 


Rest  Similarly  as  above. 


□ 


Theorem  4.2.6  (Extension  of  Theorem  4.1.13)  (Extension  substitution  application) 

T;  4>  b  t:t'  T/  b  a^, :  4/  l*;  $  b  (7  :  T  T/  b  a\j, :  T  4/  b  $  wf  T/ b  cj^,  :  T 

1. -  2. -  3. - 

T7;  $  •  b  t  ■  :  t'  ■  4b;  $  •  b  a  ■  :§'  ■  4b  b 

Tb  T:K  Tb(7$:f  T'bu^iT  T"  b  :  T' 

4b  b  T  ■  :  K  ■  T"  b  :  T 

Proof.  We  extend  our  previous  proof  as  follows. 

Case  Var. 

/  $.L  =  t 

\T;  4>  b  vL:t 

We  have  (4>  • 
get  the  desired 


,).(L  ■  <jq,)  =  (4>.L)  ■  <Jq  =  t  ■  <7q  from  Lemma  4.2.3.  Thus  using  the  same  rule  for  vL.  we 
result. 


Case  SubstCVar. 

/T;  $  b  a  :  4b  T.z  =  [$/]  ctx  $>',  cf>j  C  4>\ 

\  $b(u,  id(^J):($',  <^)  / 

In  this  case  we  need  to  prove  that  4b;  $  •  a^,  b  (a  •  a^,  ida  ■ ) :  (4b  •  <tvI,.z). 

By  induction  hypothesis  for  a  we  get  that  4b;  $  •  a^,  b  n  •  a^, :  4b  •  n^,. 

Also,  we  have  that  4b  b  a^.i  :  T.z  •  a^. 

Since  T.z  =  [4b]  rtx  this  can  be  rewritten  as:  4//  b  a^.i  :  [4b  •  cr^]  ctx. 

By  typing  inversion  get  a^.i  =  [4b  •  cr^,]  4>"  for  some  4>"  and: 

4//  b  [4b  •  o\j,]  4>x/ :  [4b  •  a^,]  ctx. 

Now  proceed  by  induction  on  4>"  to  prove  that 
4b;  4>  •  ay  b  (a  ■  a^,  ida }  j) :  (4b  •  a a^.i). 

When  4>"  =  •,  trivial. 

When  4>//  =  4b",  t,  have  4b;  L  ^  b  <j  •  zc/jy.^  :  (4b  •  ay  4>///)  by  induction  hypothesis.  We 
can  append  ^|^/.cr>I/|_j_|^///|  to  this  substitution  and  get  the  desired,  because  (|4b  •  a\j,|,  |4b"|)  <  |4>  •  cy  |.  This  is 

3.  Typing  will  require  that  $  •  cr^  =  $  •  (o\j,  •  a'^) 
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because  (<1>7,  <f>t)  C  $  thus  (<fr7  •  a^,  ,  t)  C  <t>  and  (|$/  •  +  |3>777|  +  1)  <  |3>|. 

When  <1>77  =  4>777,  <f>j,  have  Sb';  $  •  <jq,  h  a  ■  axV,  id^ -cr  ]$"/  :  •  cr^,  4>777).  Now  we  have  that  <j>l  C  $, 

which  also  means  that  (4>7  •  o\j,,  4>777,  ^  ■)  C  $  •  a^.  Thus  we  can  apply  the  typing  rule  for  id(<^  ■)  to  get  that 
'P';  $  •  b  a  ■  vy,  id (<j>j) :  ($7  •  axV,  $///,  which  is  the  desired. 

Case  CtxCVar. 

/  T  b  <5  wf  T.i  =  [$]  ct%\ 

\  Th($,  ^Jwf  / 

By  induction  hypothesis  we  get  'B/  h  $  •  wf. 

Also,  we  have  that  V  h  a^.i  :  T.i  •  ay,. 

Since  T.i  =  [$]  ctx  the  above  can  be  rewritten  as  T7  b  oy,.z  :  [4>  •  ay,]  ctx. 

By  inversion  of  typing  get  that  oy,.z  =  [4>  •  o\[;]  T7  and  that  T7  h  T  •  ay,,  T7  wf.  This  is  exactly  the  desired 
result. 


Case  ExtCtxInst. 

/  T  b  4>,  <1>7  wf 
y  T  b  [<£]  $7 :  [<1>]  ctx 


By  use  of  part  3  we  get  T7  b  4>  •  ay,,  4>7  •  a q,  wf. 

Thus  by  the  same  typing  rule  we  get  exactly  the  desired. 

Case  ExtSVar. 


T7bc7*:T  f7b  T  :  A  •  ay 


V  'B7  b  (oy,,  T) :  (T,  K)  ) 

By  induction  hypothesis  we  get  T77  b  ay,  •<  :T. 

By  use  of  part  4  we  get  T77  b  T  ■  <j(v  :  (K  ■  oy,)  ■  a^. 

This  is  equal  to  K  ■  ( oy,  •  a' )  by  use  of  Lemma  4.2.5.  Thus  we  get  the  desired  result  by  applying  the  same 
typing  rule.  □ 


4.3  Constant  schemata  in  signatures 

The  dHOL  logic  as  presented  so  far  does  not  allow  for  polymorphism  over  kinds.  For  example,  it  does 
not  support  lists  List  a  :  Type  of  an  arbitrary  a  :  Type  kind,  or  types  for  its  associated  constructor  ob¬ 
jects.  Similarly,  in  order  to  define  the  elimination  principle  for  natural  numbers,  we  need  to  provide  one 
constant  in  the  signature  for  each  individual  return  kind  that  we  use,  with  the  following  form: 

elimNatfc  :  1C  —*■  ( Nat  — »•  /C  — *  1C)  — »■  (Nat  — *■  1C) 

Another  similar  case  is  the  proof  of  symmetricity  for  equality  given  in  Section  3.2,  which  needs  to  be 
parametric  over  the  kind  of  the  involved  terms.  One  way  to  solve  this  issue  would  be  to  include  the 
PTS  rule  (Type  ,  Type,  Type)  in  the  logic;  but  it  is  well  known  that  this  leads  to  inconsistency  because  of 
Girard’s  paradox  [Girard,  1972,  Coquand,  1986,  Hurkens,  1995] .  This  in  turn  can  be  solved  by  supporting 
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(, Signature )  X  ::=  •  |  X,  c  :  [$]  t 
( Logical  terms)  t  ::=  c/a  \  •  •  • 


bXwf  •;  •  \~y  [$]  t :  [$]  s  (c  :  WX 

- SigEmpty  - - — - ~  SigConst 

b  •  wf  b  X,  c  :  [<£]  t  wf 


the  rule  CONSTANT  is  replaced  by: 
c  :  [V]  t'eX  \P;  $  b  <7  :  $/ 

- 7 - CONSTSCHEMA 

T;  $  bs  c/a  :  t  •  a 


Figure  4.12:  Extension  to  aHOL  with  constant-schema-based  signatures:  Syntax  and  typing 

a  predicative  hierarchy  of  Type  universes.  We  will  consider  a  different  alternative  instead:  viewing  the 
signature  X  as  a  list  of  constant  schemata  instead  of  a  (potentially  infinite)  list  of  constants.  Each  schema 
expects  a  number  of  parameters,  just  as  elimNat  above  needs  the  return  kind  K,  as  a  parameter;  every 
instantiation  of  the  schema  can  then  be  viewed  as  a  different  constant.  Therefore  this  change  does  not 
affect  the  consistency  of  the  system,  as  we  can  still  view  the  signature  of  constant  schemata  as  a  signature 
of  constants. 

This  description  of  constant  schemas  corresponds  exactly  to  the  way  that  we  have  defined  and  used 
meta-variables  above.  We  can  see  the  context  that  a  meta-variable  depends  on  as  a  context  of  parameters 
and  the  substitution  required  when  using  the  meta-variable  as  the  instantiation  of  those  parameters.  There¬ 
fore,  we  can  support  constant  schematas  by  changing  the  signature  X  to  be  a  context  of  meta-variables 
instead  of  a  context  of  variables.  We  give  the  new  syntax  and  typing  rules  for  X  in  Figure  4.12.  We  give 
an  example  of  using  constant  schemata  for  the  definition  of  polymorphic  lists  in  Figure  4.13,  where  we 
also  provide  constants  for  primitive  recursion  and  induction  over  lists.  We  use  named  variables  for  pre¬ 
sentation  purposes.  We  specify  the  substitutions  used  together  with  the  constant  schemata  explicitly;  in 
the  future  we  will  omit  these  substitutions  as  they  are  usually  trivial  to  infer  from  context.  Our  version  of 
/HOL  supports  inductive  definitions  of  kinds  and  propositions  that  generate  a  similar  list  of  constants. 

It  is  trivial  to  adapt  the  metatheory  lemmas  we  have  proved  so  far  in  order  account  for  this  change.  In¬ 
tuitively,  we  can  view  the  variable-based  X  context  as  a  special  variable  context  <lv  that  is  always  prepended 
to  the  actual  $  context  at  hand;  the  metavariable-based  X  is  a  similar  special  metavariable  context  The 
adaptation  needed  is  therefore  exactly  equivalent  to  moving  from  the  CONSTANT  rule  that  corresponds 
to  the  Var  rule  for  using  a  variable  out  of  a  $  context,  to  the  ConstSchema  rule  corresponding  to  the 
MetaVar  rule  for  using  a  metavariable  out  of  T.  Since  we  have  proved  that  all  our  lemmas  still  hold  in 
the  presence  of  the  MetaVar  rule,  they  will  also  hold  in  the  presence  of  ConstSchema.  With  the  for¬ 
mal  description  of  constant  schemata  in  place,  we  can  make  the  reason  why  the  consistency  of  the  logic 
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List 

[a :  Type]  Type 

nil 

[a  :  Type]  List /(a) 

cons 

[a  :  Type]  a  — *  List /(a)  — >  List /(a) 

elimList 

[a  :  Type,  T  :  Type] 

T  (a  List /(a)  ->T  —>T)—>  (List /(a)  T) 

elimListNil 

[a  :  Type,  T  :  Type] 

V  fn  :  T.V  fc:  a  — ►  List /a  — ►  T  —*T. 
elimList  [(a,  T)  fn  fc  nil /a  =  fn 

elimListCons 

[a  :  Type,  T  :  Type] 

V f„  :  T.V fc:  a  —*  List/ a  — *  T  —*■  T.V t :  a. V /  :  List/ a. 
elimList /(a,  T)  fn  fc  (cons/ a  t  /)  = 
fc  t 1  (elimList /(a,  T)  fn  fc  l) 

indList 

[a  :  Type,  P  :  List/ a  — >  Type] 

P  nil/ a  —>(Vt:  aNl  :  a.P  l  —>  P  (cons/a  t  /))  — * 

V/  :  List /a.P  l 

Figure  4. 13:  Definition  of  polymorphic  lists  in  /HOL  through  constant  schemata 


is  not  influenced  precise:  extension  terms  and  their  types,  where  the  extra  dependence  on  parameters  is 
recorded,  are  not  internalized  within  the  logic  -  they  do  not  become  part  of  the  normal  logical  terms. 
Thus  [Type]  Type  is  not  a  Type,  therefore  Type  is  not  predicative  and  Girard’s  paradox  cannot  be  encoded. 

4.4  Named  extension  variables 

We  have  only  considered  the  case  where  extension  variables  Xt  and  <b;  are  free.  This  is  enough  in  order 
to  make  use  of  extension  variables  in  /HOL,  as  the  logic  itself  does  not  include  constructs  that  bind  these 
kinds  of  variables.  Our  computational  language,  on  the  other  hand,  will  need  to  be  able  to  bind  extension 
variables.  We  thus  need  to  extend  zHOL  so  that  we  can  use  such  bound  extension  variables  in  further 
logical  terms. 

In  the  interests  of  avoiding  needlessly  complicating  our  presentation,  we  will  use  named  extension 
variables  instead  in  our  description  of  the  computational  language,  which  follows  in  Chapter  6.  As  men¬ 
tioned  earlier  in  Section  4.1,  our  original  choice  of  using  hybrid  deBruijn  variables  for  extension  vari¬ 
ables  is  not  as  integral  as  it  is  for  normal  variables;  we  made  it  having  future  extensions  in  mind  (such 
as  meta-N-variables)  and  in  order  to  be  as  close  as  possible  to  the  variable  representation  we  use  in  our 
implementation.  We  will  thus  not  discuss  the  extension  with  bound  extension  variables  further,  as  using 
named  extension  variables  masks  the  distinction  between  free  and  bound  variables.  The  extension  closely 
follows  the  definitions  and  proofs  for  normal  variables  and  their  associated  freshening  and  binding  oper¬ 
ations,  generalizing  them  to  the  case  where  we  bind  multiple  extension  variables  at  once.  The  interested 
reader  can  find  the  full  details  of  this  extension  in  our  published  Technical  Report  [Stampoulis  and  Shao, 

2012b]. 

We  show  the  new  syntax  that  uses  named  extension  variables  in  Figure  4.14  and  the  new  typing  rules  in 
Figure  4.15.  The  main  change  is  that  we  have  included  variable  names  in  extension  contexts  and  extension 
substitutions.  We  use  V  for  extension  variables  when  it  is  not  known  whether  they  are  metavariables  X 


75 


{Logical  terms)  t  ::=X/a 
{Parametric  deBruijn  levels)  L  ::=  0  |  L  +  1  |  L  +  |^| 

{Contexts)  $  ::=  •  •  •  |  (f> 

{Substitutions)  a  ::=•••  |  a,  id(^) 

{Extension  variables)  V  ::=X\<f> 

{Extension  terms)  T  ::=  [$]  t  |  [<1>]  & 

{Extension  types)  K  ::=  [4>]  t  |  [$]  ctx 

{Extension  contexts)  T  ::=  •  |  T,  V  :K 
{Extension  substitutions)  ::=  •  |  axV,  T /V 

Figure  4. 14:  aHOL  with  named  extension  variables:  Syntax 

or  context  variables  cf>.  Furthermore,  instead  of  using  integers  to  index  into  contexts  and  substitutions 
we  use  names.  The  connection  with  the  formulation  where  extension  variables  are  deBruijn  indices  is 
direct.  Last,  we  will  sometimes  use  the  standard  substitution  notation  T'[T /V]  to  denote  the  operation 
T  ■  (idy]n  T /V),  when  the  exact  T  context  needed  is  easily  inferrable  from  the  context. 
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\E  bs  <E  wf 


$  I-  a  : 


T;  <E  b  t  :  t' 


\E  b  <E  wf  \E.d>  =  r<£l  ctx 

- - - — - CtxCVar 

'I'  b  (<E,  <f>)  wf 


\E;  $  b  <r  :  '1 1  .cf>  =  [$/]  ctx  (4b,  cf>)  C  <E 

id(«^)):($',  <f>) 


SubstCVar 


TJf  =  T 


T  =  [4b]  t '  'I1;  $  b  a  :  4>; 

- - - MetaVar 

T;  ^hX/a-.t'-a 


b  \E  wf 


- ExtCEmpty 

b  •  wf 


b  \E  wf  \E  b  4>  wf 

- ExtCMeta 

b  (T,  <j)  :  [4>]  ctx)  wf 


b  \E  wf  'E  b  [<E]  t :  [4>]  5 

- ExTCCTX 

b  (\E,  X  :  [<E]  t )  wf 


\E  b  aq, :  4b 


- ExtSEmpty 

'Eb»:« 


'E  b  aw  :  'E/  \E  b  T  :K  ■ 

- - - -  ExtSVar 

'EbK,  T/V):(V',V:K) 


Figure  4.15:  7HOL  with  named  extension  variables:  Typing 
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Chapter  5 

The  logic  dHOL:  Pattern  matching 


Having  presented  dHOL  with  extension  variables,  we  are  ready  to  proceed  to  the  main  operation  through 
which  xHOL  terms  are  manipulated  in  VeriML:  pattern  matching.  We  will  first  describe  the  procedure 
and  metatheoretic  proofs  for  matching  a  scrutinee  against  a  pattern  in  Section  5.1.  In  Section  5.2,  we  will 
present  an  approach  that  enables  us  to  use  the  same  pattern  matching  procedure  when  the  scrutinee  is  not 
closed  with  respect  to  extension  variables. 

5.1  Pattern  matching 

In  Section  2.3  we  noted  the  central  importance  that  pattern  matching  constructs  have  in  VeriML.  We 
presented  two  constructs:  one  for  matching  over  contextual  terms  and  one  for  matching  over  contexts. 
Having  seen  the  details  of  extension  terms  in  the  previous  chapter,  it  is  now  clear  that  these  two  constructs 
are  in  fact  a  single  construct  for  pattern  matching  over  extension  terms  T .  In  this  section  we  will  give 
the  details  of  what  patterns  are,  how  unification  of  a  pattern  against  a  term  works  and  prove  the  main 
metatheoretic  result  about  this  procedure. 

Informally  we  can  say  that  a  pattern  is  the  ‘skeleton’  of  a  term,  where  some  parts  are  specified  and  some 
parts  are  missing.  We  name  each  missing  subterm  using  unification  variables.  An  example  is  the  following 
pattern  for  a  proposition,  where  we  denote  unification  variables  by  prefixing  them  with  a  question  mark: 

?P  A  (Vx  :  Nat.}Q) 

A  pattern  matches  a  term  when  we  can  find  a  substitution  for  the  missing  parts  so  that  the  pattern  is 
rendered  equal  to  the  given  term.  For  example,  the  above  pattern  matches  the  term  (fix  :  Nat.x  +  x  > 
x)  A  (Vx  :  Nat.x  >  0)  using  the  substitution: 

?P  (Vx  : Nat.x  +  x  >  x),  ?Qi-»x>0 

As  the  above  example  suggests,  unification  variables  can  be  used  in  patterns  under  the  binding  con¬ 
structs  of  the  /HOL  logic.  Because  of  this,  if  we  view  unification  variables  as  typed  variables,  their  type 
includes  the  information  about  the  variables  context  of  the  missing  subterm,  in  addition  to  its  type.  It  is 
therefore  evident  that  unification  variables  are  a  special  kind  of  meta-variables;  and  that  we  can  view  the 
substitution  returned  from  pattern  matching  as  being  composed  from  contextual  terms  to  be  substituted 
for  these  (unification)  meta-variables.  The  situation  for  matching  contexts  against  patterns  that  include 
context  unification  variables  is  similar.  Therefore  we  can  view  patterns  as  a  special  kind  of  extension 
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terms  where  the  extension  variables  used  are  viewed  as  unification  variables.  We  will  place  further  restric¬ 
tions  on  what  terms  are  allowed  as  patterns,  resulting  in  a  new  typing  judgement  that  we  will  denote  as 
'hi p  T  :K.  Based  on  these,  we  can  formulate  pattern  matching  for  dHOL  as  follows.  Assuming  a  pattern 
Tp  and  an  extension  term  T  (the  scrutinee)  with  the  following  typing: 

Vu\pTP:K  and  .hT:I 

where  the  extension  context  describes  the  unification  variables  used  in  Tp,  pattern  matching  is  a 
procedure  which  decides  whether  a  substitution  o\[;  exists  so  that: 

•  b  ay  :  and  TP-a^  =  T 

We  will  proceed  as  follows. 

1.  First,  we  will  define  the  typing  judgement  for  patterns  'F  Ip  T  :K.  This  will  be  mostly  identical  to 
the  normal  typing  for  terms,  save  for  certain  restrictions  so  that  pattern  matching  is  decidable  and 
deterministic. 

2.  Then,  we  will  define  an  operation  to  extract  the  relevant  variables  out  of  typing  derivations;  it  will 
work  by  isolating  the  partial  context  that  gets  used  in  a  given  derivation.  This  is  useful  for  two 
reasons:  first,  to  ensure  that  all  the  defined  unification  variables  get  used  in  a  pattern;  otherwise, 
pattern  matching  would  not  be  deterministic  as  unused  variables  could  be  instantiated  with  any 
arbitrary  term.  Second,  isolating  the  partial  context  is  crucial  in  stating  the  induction  principle 
needed  for  the  pattern  matching  theorem  that  we  will  prove. 

3.  Using  this  operation,  we  will  define  an  even  more  restrictive  typing  judgement  for  patterns,  which 
requires  all  unification  variables  defined  to  be  relevant,  ruling  out  in  this  way  variables  that  are  not 
used.  A  sketch  of  its  formal  definition  is  as  follows: 

T,  I PTP-.K  relevant  ('F,  1 PTP:K)  =  ■■■ , 

^^h>Tp:K 

Let  us  explain  this  rule  briefly.  First,  'F  represents  the  normal  extension  variables  whereas  lF;( 
represents  the  newly-defined  unification  variables.  The  judgement  'F  l£  vFa  >  Tp  :  K  is  understood 
as:  “in  extension  context  'F,  the  introduction  of  the  unification  variables  lIy,  renders  Tp  a  valid 
pattern  of  extension  type  K”.  The  second  premise  of  this  rule  uses  the  operation  that  extracts 
relevant  variables  out  of  a  derivation  in  order  to  make  sure  that  all  unification  variables  are  relevant. 
We  will  prove  a  substitution  theorem  for  this  rule,  with  the  following  formal  statement: 

'FF'F„>rp:A 

-  Substitution  lemma 

V'  %  Vu  ’  >  Tp  '  :  K ' 

This  theorem  extends  the  extension  substitution  theorem  4.2.6  so  as  to  apply  to  the  case  of  patterns 
as  well. 

4.  Based  on  these,  we  will  prove  the  fact  that  pattern  matching  is  decidable  and  deterministic.  We  will 
carry  out  the  proof  in  a  constructive  manner;  its  computational  counterpart  will  be  the  pattern 
matching  algorithm  that  we  will  use.  Therefore  the  pattern  matching  algorithm  will  be  sound  and 
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complete  directly  by  construction.  The  algorithm  thus  produces  a  substitution  of  instantiations 
to  the  unification  variables  making  the  pattern  and  the  scrutinee  match,  when  one  such  substitution 
exists;  or  fails,  when  there  is  no  such  substitution.  We  write  Tp  ~  T  =  for  an  execution  of 
this  algorithm  between  the  pattern  Tp  and  the  scrutinee  T,  when  it  results  in  a  substitution  ayV . 
Formally,  the  statements  of  the  related  theorems  we  will  prove  are  as  follows. 

*^p^u>  Tp  -K  »\~T  :K  Pattern  matching 

3-V^.(  .b  Tp-aq,  =  T  )  DETERMINISM  AND  DECIDABILITY 

•  ^  >  Tp  •  K  »\~T  :K  Tp  ~  T  =  aq,  pattern  matching 

. b  TP  ■  ayl,  =  T  algorithm  soundness 

m>Tp:K  *h T:K 

3°Y-(  •  h  Tp-a^  =  T  )  pattern  matching 

Tp  ~  T  =  CTq  ALGORITHM  COMPLETENESS 


Pattern  typing 

In  Figures  5.1  and  5.2  we  give  the  details  of  pattern  typing.  The  typing  judgements  use  the  extension 
context  T,  T(<,  composed  from  the  normal  extension  variable  context  T  and  the  context  of  unification 
variables  u.  We  will  define  the  “actual”  pattern  matching  process  only  between  a  ‘closed’  pattern  and 
a  closed  extension  term,  so  the  case  will  be  that  T  =  •,  as  presented  above.  Yet  being  able  to  mention 
existing  variables  from  an  T  context  will  be  useful  in  order  to  describe  patterns  that  exactly  match  a 
yet-unspecified  term.  It  is  thus  understood  that  even  if  a  pattern  depends  on  extension  variables  in  a  non¬ 
empty  T  context,  those  will  have  been  substituted  by  concrete  terms  by  the  time  that  the  “actual”  pattern 
matching  happens. 

The  two  kinds  of  variables  are  handled  differently  in  the  pattern  typing  rules  themselves.  For  exam¬ 
ple,  the  rule  for  using  an  exact  context  variable  PCTxCVarExact  is  different  than  the  rule  for  using  a 
unification  context  variable  PCTxCVarUnify.  The  difference  is  subtle:  the  latter  rule  does  not  allow 
existing  unification  variables  to  inform  the  well-formedness  of  the  $  context;  in  other  words,  a  unifica¬ 
tion  context  variable  cannot  be  used  in  a  pattern  after  another  unification  context  variable  has  already 
been  used.  Consider  the  pattern  cf>Q,  & , ,  where  &  |  :  [by]  ctx.  Any  non-empty  context  could  be  matched 
against  this  pattern,  yet  the  exact  point  of  the  split  between  which  variables  belong  to  the  cf>0  context  and 
which  to  (f)x  is  completely  arbitrary.  This  would  destroy  determinacy  of  pattern  matching  thus  this  form 
is  disallowed  using  this  rule. 

Metavariables  typing  in  patterns  is  similarly  governed  by  two  rules:  PMETAVAREXACT  and  PMeTaVarUnif. 
The  former  is  the  standard  typing  rule  for  metavariables  save  for  a  sort  restriction  which  we  will  comment 
on  shortly.  The  latter  is  the  rule  for  using  a  unification  variable.  The  main  restriction  that  it  has  is  that  the 
substitution  a  used  must  be  the  identity  substitution  -  or  more  accurately,  the  identity  substitution  for 
a  prefix  of  the  current  context.  If  arbitrary  substitutions  were  allowed,  matching  a  pattern  XJ a  against 
a  term  t  would  require  finding  an  inverse  substitution  a~l  and  using  t  ■  <t~'  as  the  instantiation  for  Xt, 
so  that  t  ■  (7_ 1  •  a  =  t.  This  destroys  determinacy  of  pattern  matching,  as  multiple  inverse  substitutions 
might  be  possible;  but  it  also  destroys  decidability  if  further  unification  variables  are  allowed  inside  a,  as 
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V  Ip  vu  wf 


'E  fp  •  wf 


UVarEmpty 


'E  Ip  'Ey  wf  'E,  'Ey  Ip  [$]  t  :  [$] : 


[$] 

'E  Ip  'Ey  wf  'E,  'Ey  Ip  $  wf 


UVarMeta 


'E  Ip  ('Ey,  [<E]  ctx)  wf 


UVarCtx 


%  'I 'u\?T:K 


'E, 


^  M  t:  [$]  l’ 


PExtCtxTerm 


'E,  'Ey  Ip  wf 
'E,  'Ey  Ip  [$]  <E/ :  [<E]  ctx 


PExtCtxInst 


'E,  'E  Ip  $  wf 


'E,  'Ey  Ip  •  wf 


PCTxExpty 


'E, 'E^lp^wf  'E,  V„;  $lp  t  :s 

'E,  'Ey  Ip  ($,  t)wf 


PCTxVar 


'E, 'Ey  Ip  <Ewf  ^<1^1  ('E,  'Ey).?  =  [3>]  ctx 

'E-  ^  &)wf 

'Elp^wf  z  >  |^E|  ('E,  'E(<).z  =  [$]  ctx 


PCTxCVarExact 


'E,  'Ey  I p  ($,  <f>{)  wf 


PCtxCVarUnif 


'E,  $\pa:& 


%  $lp»: 


■  PSubstEmpty 


'E,  'Ey;  $  Ip  a  :  <E;  'E,  'Ey?  $  Ip  t  :  t'  ■  a 

^  $lpK  0;($/- 1') 


PSubstVar 


'E,  'Ey;  $  Ip  a  :  &  ('E,  'Ea).z  =  [^jrtx  ‘E7,  cf)t  C  $ 


PSubstCVar 


Figure  5.1:  Pattern  typing  for  a  HOI. 
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c  :  t  E  £  •  h  t :  s  j  ^  Prop  <P.Z,  =  t  'P,.;  3>  h  t  :  s  s  7^  Prop 

- - -  PCONSTANT  - - - — - -  PVAR 


'P,  ^  ^  c  :  t 


'P,  \P(<;  <&\pVL\t 

'P,  yu\  ^lp  h  :s  ^  ^«5  $>  *ilp  ff2l|$| 


(s,s')G^  '*'*>'*'  |p  n  • a  ■*"’  *»>  ■*■>  '-l  'p  I  ‘"2 1|$| 

PSORT  - - - PIIType 


'P,  ;  $ks: 


:  s 


'P,  'P,,;  ^  hp  n(t1).t2  :  5 


\p;  \P  ;  $  Ip  t1 :  s 

h\p\%\\*\'t'  'P,  ^;^^n(tj). s'  ^  Prop 


PniNTRO 


'p,  'P u-,$\p  X(tx).t2-.n(tx).  [t'\mi 

^V^Qhpt^.UW.t'  (t).t':s'  s' ^  Prop 

'P,  'P H-,*\ptx  t2:  \t']^-(id^t2) 

V,VH;$lpt2:t  -pf.Type 


PIIElim 


'P,  'P„;  $1 ph  =  t2  -.Prop 


PEqType 


('P,  'P  ).z  =  T 

T  =  [^F]  t1  i  <  |\P|  'P,  \P;<;  $  Ip  a  :  'P,  \PM  \~  t' :  s'  s  /  Prop 


*>  \P(j;  ^  Ip  XJ a  :  t'  ■ 


PMetaVarExact 


a 


(*,*H).i  =  T  T  =  [*']t' 

z  >  I'Pl  'P,  \P,(;  $  Ip  a  :  $'  ^  C  <t>  a  =  id^i  \P,  'Pu  h  t' :  s'  s  ^  Prop 


*>  VsthpXi/v.t'- 


PMetaVarUnif 


a 


Figure  5.2:  Pattern  typing  for  xHOL  (continued) 
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Assuming  'I'  b  wf: 


T  =  Vt 

fa _ 


id . 

idq,i  k 

u  ’ 


[$]  when  (T,  'FJh  =  [$]  t' 

[$]  (j)t  when  (T,  'Fjh  =  [$]  ctx 


idyl  ,  Vj^,|_|_|^/  | 


•O’vlM  K-((Jy,  idyl  ) 


Figure  5.3:  Syntactic  operations  for  unification  contexts 

the  problem  becomes  equivalent  to  higher-order  unification,  which  is  undecidable  [Dowek,  2001],  Pre¬ 
fixes  of  the  identity  substitution  for  the  current  context  can  be  used  to  match  against  scrutinees  that  only 
mention  specific  variables.  For  example  we  can  use  a  pattern  like  XJ»  in  order  to  match  against  closed 
terms. 

Last,  many  pattern  typing  rules  impose  a  sort  restriction.  The  reason  is  that  we  want  to  disallow 
pattern  matching  against  proof  objects,  so  as  to  render  the  exact  structure  of  proof  objects  computation¬ 
ally  irrelevant.  We  cannot  thus  look  inside  proof  objects:  we  are  only  interested  in  the  existence  of  a 
proof  object  and  not  in  its  specific  details.  This  will  enable  us  to  erase  proof  objects  prior  to  evaluation 
of  VeriML  programs.  By  inspection  of  the  rules  it  is  evident  that  Prop- sorted  terms  are  not  well-typed 
as  patterns;  these  terms  are  exactly  the  proof  objects.  The  only  Prop- sorted  pattern  that  is  allowed  is  the 
unification  variable  case,  which  we  can  understand  as  a  wildcard  rule  for  matching  any  proof  object  of  a 
specific  proposition. 

We  will  need  some  metatheoretic  facts  about  pattern  typing:  first,  the  fact  that  pattern  typing  implies 
normal  typing;  and  second,  the  equivalent  of  the  extension  substitution  theorem  4.2.6  for  patterns.  We 
will  first  need  two  definitions  that  lift  identity  substitutions  and  extension  substitution  application  to 
unification  contexts  'P u  typed  in  a  context  T,  given  in  Figure  5.3.  In  the  same  figure  we  give  an  operation 
to  include  extension  variables  Vt  as  extension  terms,  by  expanding  them  to  the  existing  forms  such  as 
[T]  VJidy  and  [T]  Vr  We  remind  the  reader  that  Vt  stands  for  either  kind  of  an  extension  variable,  that 
is,  either  for  a  meta-variable  Xi  or  for  a  context  variable  Sr 

Lemma  5.1.1  (Pattern  typing  implies  normal  typing) 

~p^uwf  ^>^h^pT:K  p$wf 

b  T,  wf  V,  T(<  b  T  :  K  T,  b  §wf 

%*H;$\pt:t' 

4. -  5. - 

T,  T„bu:$  T,  Ta;$b  t:f 
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Proof.  Trivial  by  induction  on  the  typing  derivations,  as  every  pattern  typing  rule  is  a  restriction  of  an 
existing  normal  typing  rule.  □ 


Theorem  5.1.2  (Extension  substitution  application  preserves  pattern  typing) 
Assuming  'P/  b  a^, :  T  and  a'^  =  a^,,  id ^  , 


1. 


T,  'P„;  §\pt:t' 


T',  ^u-a^,^-a'\pt-a':t' 


a. 


2‘ 


T,  *u;  $\-pa:& 

•  $  •  <4  ^  •  <4 ;  •  <4 


3. 


T,  Ip  $  wf 
T',  •  n*  Ip  $  •  wf 


4. 


T, 


*4  *v<^r-<4:*- 


a, 


T  ly  ojf 

T  ly  •  axV  wf 


Proof.  In  most  cases  proceed  similarly  as  before.  The  cases  that  deserve  special  mention  are  the  ones  that 
place  extra  restrictions  compared  to  normal  typing. 


Case  PCtxCVarUnif. 

/  T  Ip  <P  wf  i  >  |'P|  (T,  \PM).z  =  [<P]  ctx\ 

\  ^  !p($>  <4)wf  / 

We  need  to  prove  that  T7,  u-  cr^.  Ip  $  •  <fi  •  wf. 

We  have  that  ft  ■  a'y  = 

By  induction  hypothesis  for  T,  with  =  •,  we  get: 

T  Ip  $  •  Gq,  wf  from  which  'P  Ip  •  <4  wf  directly  follows. 

We  have  i  —  |\P|  +  |'P/|  >  |'P/[  because  of  i  >  |\P|. 

Last,  we  have  that  ('P/,  \P u  ■  a^,).{i  —  |\P|  +  IT'D  =  [<P  •  a'^\ ctx. 

Thus  using  the  same  rule  PCtxCVarUnif  we  arrive  at  the  desired. 


Case  PMetaVarUnif. 

(T,  Vu).i  =  T  T=[§']t'  i  >  |\P|  T,  T^l -pa:&  C  $  a  =  id& 

T,  $1 pXJa  :  t'  ■  a 

Similar  as  above.  Furthermore,  we  need  to  show  that  id $/  •  o[v  =  id^_a' ,  which  follows  trivially  by 
induction  on 


Case  PVar. 

$.L  =  t  \P,  $  h  t  :  s  sfProp 

T,  <Pl -pvL\t 

We  give  the  proof  for  this  rule  as  an  example  of  accounting  for  the  sort  restriction;  other  rules  are  proved 
similarly.  By  induction  hypothesis  for  t  we  get: 

^  $»-(7h$'4l'£'(7rs' <4 

But  s  ■  a'^  =  s  so  the  restriction  s  f  Prop  still  holds.  □ 
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The  statement  of  the  above  lemma  might  be  surprising  at  first.  One  could  expect  it  to  hold  for  the  general 
case  where  T/  b  :  (T,  Ta).  This  stronger  statement  is  not  true  however,  if  we  take  into  account  the 
restrictions  we  have  placed:  for  example,  substituting  a  unification  variable  for  a  proof  object  will  result 
in  a  term  that  is  not  allowed  as  a  pattern.  The  statement  we  have  proved  is  in  fact  all  we  need,  as  we  will 
use  it  only  in  cases  where  we  are  substituting  the  base  T  context;  the  unification  variables  will  only  be 
substituted  by  new  unification  variables  that  are  well-typed  in  the  resulting  W  context.  This  becomes 
clearer  if  we  consider  a  first  sketch  of  the  pattern  typing  rule  used  in  the  computational  language: 

Tb  T:K  TlpT„wf  ^,^u\pTP:K 

T  •  •  •  b  match  T  with  Tp  •  •  • 

Type-safety  of  the  computational  language  critically  depends  on  the  fact  that  applying  a  substitution  o\I; 
for  the  current  T  context  yields  expressions  that  are  typable  using  the  same  typing  rule.  This  fact  is  exactly 
what  can  be  proved  using  the  lemma  as  stated. 

Relevant  typing 

We  will  now  proceed  to  define  the  notion  of  relevant  variables  and  partial  contexts.  We  say  that  a  variable 
is  relevant  for  a  term  if  it  is  used  either  directly  in  the  term  or  indirectly  in  its  type.  A  partial  context  T 
is  a  context  where  only  the  types  for  the  relevant  variables  are  specified;  the  others  are  left  unspecified, 
denoted  as  ?.  We  will  define  an  operation  relevant  (T;  •  •  • )  for  derivations  that  isolates  the  partial  context 
required  for  the  relevant  variables  of  the  judgement.  For  example,  considering  the  derivation  resulting  in: 

$ o  =  []ctx,  X \  :  [<j>0\  Type,  X2  :  [<f>0]Xv  X3  :  bX3  : 

the  resulting  partial  context  will  be: 

$  =  <t>o  '■  [~\ctX  Xx  :  [<^0]  Type,  X2  :  ?,  X3 :  [cf>Q\Xl 

where  the  variable  X2  was  unused  in  the  derivation  and  is  therefore  left  unspecified  in  the  resulting  partial 
context. 

The  typing  rule  for  patterns  in  the  computational  language  will  require  that  all  unification  variables  are 
relevant  in  order  to  ensure  determinacy  as  noted  above.  Non-relevant  variables  can  be  substituted  by 
arbitrary  terms,  thus  pattern-matching  would  have  an  infinite  number  of  valid  solutions  if  we  allowed 
them.  Thus  a  refined  sketch  of  the  pattern  match  typing  rule  is: 

Tb  T:K  T^T„wf  %VH\pTP:K 
relevant  (T,  T  J PTP:K) 

T  •  •  •  b  match  T  with  Tp  • 

In  this,  the  symbol  Q  is  used  to  mean  that  one  partial  context  is  less-specified  than  another  one.  Therefore, 
in  the  new  restriction  placed  by  the  typing  rule,  we  require  that  all  unification  variables  are  used  in  a 
pattern  but  normal  extension  variables  can  either  be  used  or  unused.  Because  of  this  extra  restriction,  we 
will  need  to  prove  a  lemma  regarding  the  interaction  of  relevancy  with  extension  substitution  application, 
so  that  the  extension  substitution  lemma  needed  for  the  computational  language  will  still  hold. 

We  present  the  syntax  and  typing  for  partial  contexts  in  Figure  5.4;  these  are  entirely  identical  to  nor¬ 
mal  T  contexts  save  for  the  addition  of  the  case  of  an  unspecified  element.  We  present  several  operations 
involving  partial  contexts  in  Figure  5.5;  we  use  these  to  define  the  operation  of  isolating  the  relevant  vari¬ 
ables  of  a  judgement  in  Figures  5.6  and  5.7.  The  rules  are  mostly  straightforward.  For  example,  in  the 
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b  T  wf  T  b  [$]  t :  [<I>]  s 
b*wf  h  ($,[$]  t)wf 


b  \P  wf  T  b  $  wf  b  \P  wf 

b(T,  [<b]  ctx)  wf  I- ('I1,  ?)wf 


Figure  5.4:  Partial  contexts  (syntax  and  typing) 


case  of  the  rule  MetaVar  for  using  metavariables,  the  relevant  variables  are:  the  metavariable  itself  (by 
isolating  just  that  variable  from  the  context  through  the  \P@z  operation);  the  relevant  variables  used  for 
the  substitution  a;  and  the  variables  that  are  relevant  for  well-typedness  of  the  type  of  the  metavariable 
t' .  The  partial  contexts  so  constructed  are  joined  together  through  the  T  o  vjd  operation  in  order  to 
get  the  overall  result.  This  is  equivalent  to  taking  the  union  of  the  set  of  relevant  variables  in  informal 
practice. 

We  are  now  ready  to  proceed  to  the  metatheoretic  proofs  about  isolating  relevant  variables. 

Lemma  5.1.3  (More  specified  contexts  preserve  judgements) 

Assuming  T  C  Tb 

T  b  T:K  T  b  §  wf  T;  $  h  t :  t'  4*;  $h(7:T 

1.  - -  2.  - -  3.  - -  4.  - - 

ThT  :K  tf'h  $wf  T';$h  t:t' 


Proof.  Simple  by  structural  induction  on  the  judgements.  The  interesting  cases  are  the  ones  mentioning 
extension  variables,  as  for  example  when  $  =  T',  <fq,  or  t  =XJ a .  In  both  such  cases,  the  typing  rule  has 
a  side  condition  requiring  that  T.z  =  T.  Since  T  C  T',  we  have  that  Tbz  =  T.z  =  T.  □ 


Lemma  5.1.4  (Relevancy  is  decidable) 

Tb  T:K 

1. 


3. 


3  W  .relevant  FT  :  K)  =  T 

T;  $\-t:t' 

3\A>. relevant  (fit;  $  b  t :  t')  =  T 


2. 


T  b  <I>  wf 


4. 


3\^h  .relevant  (fi!  h  $  wf)  =  T 

T;  $bu 
3 .relevant  {fit ;  $  b  a  :  4b)  =  T 


Proof.  The  relevancy  judgements  are  defined  by  structural  induction  on  the  corresponding  typing 
derivations.  It  is  crucial  to  take  into  account  the  fact  that  b  T  wf  and  T  b  4>  wf  are  implicitly  present  in 
any  typing  derivation  that  mentions  such  contexts;  thus  these  derivations  themselves,  as  well  as  their  sub¬ 
derivations,  are  structurally  included  in  derivations  like  \P;  $  h  t  :  ib  Furthermore,  it  is  easy  to  see  that  all 
the  partial  context  joins  used  are  defined,  as  in  all  cases  the  joined  contexts  are  less-specified  versions  of  T. 
This  fact  follows  by  induction  on  the  derivation  of  the  result  of  the  relevancy  operation  and  by  inspecting 
the  base  cases  for  the  partial  contexts  returned.  □ 
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Fully  unspecified  context: 
unspec^  =  'F 

unspec .  =  • 

unspec  K  =  unspec ? 


Partial  context  solely  specified  at  i : 

=  $ 

('F,  K)@i  =  unspec^,,  if  when  |\F|  =  z 
('F,  K)@i  =  ('Fcgz),  ?  when  |^F|  >  i 


Joining  two  partial  contexts: 
$  o  Vp'  = 


{%  K)o(*',  if ) 

($,  ?)°($',  *) 
($,  A>($',  ?) 

($,  ?)°($',  ?) 


($o$'),  if 
($o§'),M 
($0$'),  if 
('Fo'F/),  ? 


Context  \F  less  specified  than  lF/: 
$  C 

($,  if )  c  ($',  if )  <=  'Fr$/ 
OF,  ?)  c  ($/,  if)  <=  $  c 

OF,  ?)  c  ($',  ?)  <=  $  c 


Extension  substitution  application: 
(assuming  \F  h  \FW  wf) 

'F  •  o\i, 


•  •  =  • 

(vFa,  if)-o\i,  =  ^u-a^,K-(a^,,id^) 

M 


Figure  5.5:  Partial  contexts  (syntactic  operations) 
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relevant (4/  b  T  :K)  =  'S> 


relevant 


relevant 


~t:t'  'b;$bt/: 


:  s 


^  h  [<b]  t  :  [<b]  t 
4/  b  4>,  4b  wf 


=  relevant  (4>;  $  b  t  :  t') 


'I'  b  [4>]  4b :  [4>]  ctx 


=  relevant  ('I'  b  4>,  4>x  wf) 


relevant  (4>  b  $  wf)  =  'I' 


:  unspecy. 


( 

relevant  - 

y 'b  b  •  wfy 

/41b4>wf  4/;4>bi:s\ 

relevant  (  - - - - -  =  relevant ('b;  $  b  t :  s) 


relevant 


y  4>  b  (4>,  t)  wf 

/4,b4>wf  ('b).z  =  [4>]  ctx' 

V  ^b($,  <^)wf 


=  relevant  (4/  b  $  wf)  o  (\b@i ) 


relevant  ('b;  $  b  a  :  4b)  =  'b 


relevant 


relevant 


(- 


y  'b-  $  b  )  =  re^evant  ^  ^  wf) 

/4/;4>b<T:4>/  'b;  $  b  t :  t'  ■  a  \ 


y  4?;  $b(a,  t)  :($  ,  t  )  ) 

=  relevant  ('b;  $  b  a  :  4b)  o  relevant  (4>;  $  b  t  :  t'  ■  n) 


relevant  I 


/'b;  $  b  a  :  4b  4/.z  =  [4b]  ctx  4b,  <f>l  C  $ 


'b;  $b(>,  id <f>{ 


=  relevant  ('b;  $  b  a  :  4b) 


Figure  5.6:  Relevant  variables  of  /HOL  derivations 
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relevant  ('F;  $  h  t  :  t')  =  'I1 


relevant 


relevant 


relevant 


(  c:teT.  \ 

I  -  I  =  relevant  ('I'  h  wf) 

\  j  $  I  c  » t  J 

/  $.L  =  t  ' 
yfF;  $  b  vL  :  t 


=  relevant  (\F  b  4>  wf) 


relevant 


^  ^  ^  -  J  =  relevant  (\F  h  <F  wf) 

\F;  <F  h  £j  :  s  ft1;  tx  h  [f2]|$|  :  s'  (s,s',s")eK 


'I';  $hn(t1).t2:s/- 

=  relevant  (\F;  <F,  tl  F  [ t2l|$|  :  5/) 


relevant 


|$|+i 


^  ^  ^(h)-h  ■  n(?i).  Lf/J|$|+i 

=  relevant  (ft1;  <F,  t{  h  [^21|$|  :  j/) 


J 


relevant 


^  I-  t2:t\ 


t2:  \t']m-(id^,t2)  J 

=  relevant  ('P;  $  h  tt  :  n(t).t/)  o  relevant ('P;  $  h  t2  :  t) 


/\F;  $  h  fj  :  t  \F;  $  h  f2  :  £  \F;  <F  h  £  :  Type\ 

relevant  -  = 

y  \F;  $  b  tx  =  £2  :  Prop  J 

=  relevant (\F;  $  h  tt  :  t)  o  relevant (\F;  $  h  £2  :  £) 


f(V).i  =  T  T  =  [<S>']t' 

relevant  - 7 -  = 

\  QhXi/a-.t'-a  J 

=  relevant  ('F  h  [4F]  t' :  [<E>/]  5)  o  relevant  (\F;  $  h  a  :  <FX)  o  (\F@z) 


Figure  5.7:  Relevant  variables  of  aHOL  derivations  (continued) 
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Lemma  5.1.5  (Relevancy  soundness) 


'LL  T:K 

relevant  ('L  b  T  :K)  =  '£ 

1. - - - 

'P;  <Pb  t :  t' 

relevant  (\P;  $  b  t  :  t')  =  'P 

3- - ^ - - - 

'P;  <Pb  t :  t' 

Proof.  By  induction  on  the  typing  derivations. 


dl  b  <P  wf 

relevant  ('P  b  $  wf)  =  \P 

*P  b  <P  wf 

'P;  $  h  a  :  $' 

relevant  ('P;  $  h  a  :  3b)  =  'P 
$  h  a  :  $' 


Theorem  5.1.6  (Interaction  of  relevancy  and  extension  substitution) 

Assuming  'P/  b  ctq, :  'P,  'P  b  \PM  ewj’ ' UTld  (7 ^  ? 

unspecq,  [I  relevant  (^,  h  T  \K) 
unspeCq,,  u  ■  <jq,  C  relevant  (V,  'P H  ■  b  T  •  :  K  ■  a'^f) 

unspecq,,  'P u  Q  relevant  ('P,  3^  b  <P  wf) 
unspecq,/ ,  'P H  ■  <jq,  C  relevant  ('P/,  'P^  •  aq,  b  $  •  wf) 

unspeCq,,  XV u  C  relevant  ('P,  3/^;  3>  b  £  :  b) 
unspecq,* ,Al u  ■  aq,  Q  relevant  (V,  3»„  ■  aq,;  <P  •  h  t  •  :  t'  ■  af) 

unspeCq,, 'P u  Q  relevant  ('P,  3^;  $h(T  :  3>;) 

4. - — - 

unspeCq,, p Vu  ■  aq,  C  relevant  ()!>' ,  3»(<  •  h  a  ■  :  $'  •  ctQ 

Proof.  Proceed  by  induction  on  the  typing  judgements.  We  prove  two  interesting  cases. 

Case  CtxCVar. 

/'P,  31  a  b3>wf  ('P,  3^).z  =  [3>]  ctx  \ 

\  ^  h($,  ^-)wf  / 

We  have  that  unspeCq,,  ^ u  C  relevant  ('P,  3^  h  3b  wf)  o  (('P,  'P u)@i). 

We  split  cases  based  on  whether  i  <  |lP|  or  not. 

In  the  first  case,  the  desired  follows  trivially. 

In  the  second  case,  we  assume  without  loss  of  generality  3^  such  that 
unspeCq,,  3d  C  relevant  ('P,  XV u  h  3>;  wf)  and 
unspeCq,,  3>a  =  ( unspeCq, ,  $/w)o(('P,  'P u)@i) 

Then  by  induction  hypothesis  we  get: 

unspeCq, /,  3b  ■  (jqj  C  relevant  (V,  3^  ■  dq,  h  wf) 

Now  we  have  that  ($',  Xf  ■  =  <P'  •  a'^,  X-_^|+^/|.  Thus: 


□ 
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relevant  (T7,  ■  a^,  h  (<I>7,  Xt)  ■  wf)  = 

=  relevant  (V,  ^ u  ■  h  ($7  •  -X'i_|^/|_l_|Vl,'|)  wf) 

=  relevant  (V,  ^  •  a^,  h  $7  •  wf)  o  ((T7,  Ta  ■  a^)@(i  -  |T|  +  |T7|)) 

Thus  we  have  that:  ^ 

{unspec^,  &u  ■  a9)  o  ((T7,  T(<  •  o\j,)@(i  -  |T|  +  IT'D)  C 
C  relevant  (V,  •  o\j,  h  (V,  Xt)  ■  <j[v  wf) 

But  (unspecq,/,  •  a9)  o  ((T7,  •  o\j,)@(z  -  |T|  +  |T7|))  =  unspec T„  •  axV. 

This  is  because  ( unspec Ta)  =  ( unspec T7()  o  ((T,  Tw)@z),  so  the  i-th  element  is  the  only  one  where 
unspec q,' B7;  might  differ  from  unspec^,' B„;  this  will  be  the  i  —  |T|  +  |T7|-th  element  after  a'^  is  applied; 
and  that  element  is  definitely  equal  after  the  join. 


Case  MetaVar. 


\%VH).i  =  T  r=[$7]t7  %  $ha:$7' 

^,^u;^\-Xt/a  :t' -a 


We  split  cases  based  on  whether  i  <  |T|  or  not.  In  case  it  is,  the  proof  is  trivial  using  part  4.  We  thus  focus 
on  the  case  where  i  >  |T|.  We  have  that: 
unspecq,,  T  C  relevant  (T,  h  [$7]  t :  [4>7]  s)  o  relevant  (T,  $h<7:  <I>7)  o 

°((T,  T u)@i) 

Assume  without  loss  of  generality  T* ,  W  ,  T”  such  that 

|'E|+|'I'J1|— i  times 

ft/1  —  fih  >  ...  ? 

u~  •’  ’•  ’ 

unspec V  C  relevant  {fph  u) |,-h  [4>7]  t :  [4>7]  s), 
unspec y,  'll2  C  relevant  (T,  $  h  a  :  $7) 

and  last  that  T  =  flT  o  T2  o  ((T,  ^ u@i)). 

By  induction  hypothesis  for  [T7]  t'  we  get  that: 

unspec y,,  T7(  •  axV  C  relevant  (V,  -  <7^  h  [<h7  •  t7  •  :  [$'  •  o^]  s  ■  o^) 

By  induction  hypothesis  for  a  we  get  that: 

unspec yi,  T2  •  □  relevant  (V,  T(<  •  $  •  a'^  h  a  •  :  $7  •  cr^) 

We  combine  the  above  to  get  the  desired,  using  the  properties  of  join  and  @  as  we  did  earlier.  □ 


We  will  now  combine  the  theorems  5.1.2  and  5.1.6  into  a  single  result.  We  first  define  the  combined 
pattern  typing  judgement: 

'h  Ip  wf  T,  Ip  TP  :  K  unspec^,  C  relevant  (T,  Ip  TP  :  A) 

*Pp*u>TP:K 

Then  the  combined  statement  of  the  two  theorems  is: 
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•  b.:. 


•  |  Cty)  T  |  Pqj,  ? 

•  bhjjb'P  •  b  7’ :  A'  •  3\j,  •  ly  5\j, :  \P 

•  Ip  (oj,  T):($,  if)  •  Ip  (oj,  ?):($,  ?) 

Figure  5.8:  Partial  substitutions  (syntax  and  typing) 

Theorem  5.1.7  (Extension  substitution  for  combined  pattern  typing) 

*\*p*u>TP:K  tt'bag:* 

^  U  '  a'V  >  Tp  ■  Vy  '■  K  ■  <J,V 

Proof.  Directly  by  typing  inversion  of  typing  for  TP  and  application  of  theorems  5.1.2  and  5.1.6.  □ 

Pattern  matching  procedure 

We  are  now  ready  to  define  the  pattern  matching  procedure.  We  will  do  this  by  proving  that  for  closed 
patterns  and  terms,  there  either  exists  a  unique  substitution  making  the  pattern  equal  to  the  term,  or  no 
such  substitution  exists  -  that  is,  that  pattern  matching  is  decidable  and  deterministic.  The  statement  of 
this  theorem  will  roughly  be: 

If  \PW  Ip  Tp  :  K  and  •  b  T  :  K  then  either  there  exists  a  unique  a ^  such  that 

•  b  <7^  :  \PW  and  Tp  ■  =  T  or  no  such  substitution  exists. 

Note  that  the  first  judgement  should  be  understood  as  a  judgement  of  the  form  \P,  \PW  \j,  Tp  :  K  as  seen 
above,  where  the  normal  context  'P  is  empty.  The  computational  content  of  this  proof  is  the  pattern 
matching  procedure. 

In  order  to  do  the  proof  of  the  pattern  matching  algorithm  by  induction,  we  need  an  equivalent  lemma 
to  hold  at  the  sub-derivations  of  patterns  and  terms  representing  the  induction  principle,  such  as: 

If  \PK;  $  I \p  tP  :  t1  and  •;  $  b  t  :  t’  then  either  there  exists  a  unique  such  that 

•  b  dq, :  'P,,  and  tP  ■  o\j,  =  t  or  no  such  substitution  exists. 

Such  a  lemma  is  not  valid,  for  the  simple  reason  that  the  \P„  variables  that  do  not  get  used  in  tP  can  be 
substituted  by  arbitrary  terms.  Our  induction  principle  therefore  needs  to  be  refined  so  that  only  the 
relevant  partial  context  \P;<  is  taken  into  account.  Also,  the  substitution  established  needs  to  be  similarly 
a  partial  substitution,  only  instantiating  the  relevant  variables. 

We  thus  define  this  notion  in  Figure  5.8  (syntax  and  typing)  and  provide  the  operations  involving 
partial  substitutions  in  Figure  5.9.  Note  that  applying  a  partial  extension  substitution  d)v  is  entirely 
identical  to  applying  a  normal  extension  substitution.  It  fails  when  an  extension  variable  that  is  left 
unspecified  in  of,  gets  used,  something  that  already  happens  from  the  existing  definitions  as  they  do  not 
account  for  this  case.  With  these  definitions,  we  are  able  to  state  a  stronger  version  of  the  earlier  induction 
principle,  as  follows: 
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Joining  two  partial  substitutions: 

°  =  Ap 

•  o  •  =  • 

(oj,  T)o(5rJ/,  T)  =  (o^ooy'),T 

(<Ty,  ?)°(<V,  T)  =  (dj  o^'),  T 

(<Ty,T)  o(jry',})  =  (^o^),T 

(tf* ,  ?)  °  (<7tf ',  ?)  = 

Fully  unspecified  substitution: 
unspec^  =  dj 

unspec #  =  ? 

unspec ^  ?  =  unspec -j,  ? 

unspec-’  K  =  unspec^,  ? 


Less  specified  substitution: 

!=  <J>I/ 

(dj,  T)  C  (dj7,  T)  -<=  djcdj' 

(typj  i1)  !=  ,  T)  (7^  ^ 

^  (u",|,  5  @ Xfy  != 

Limiting  to  a  partial  context: 

°yI§  = 

(•)!.  =  * 

(£r\Ir’  —  cr'3>  1$ ’  ^ 

(^>  T)k,K  =  ^1$’  T 
(o’g/)  ^)l$j  ?  —  ^ 


Replacement  of  unspecified  element  at  index: 

dj[z  <-*■  T]  =  d^ 

(dj,  ?)[z  T]  =  dj,  T  when  i  =  |d^| 

(dj,  ?)[z T]  =  dj[i  T],  ?  when  i  <  |dj| 

(cr^,  7’/)[z  T]  =  d^,[i  >->■  T],  T  when  i  < 


Figure  5.9:  Partial  substitutions  (syntactic  operations) 

If  Ta;  $  I p  tP  :  t'  and  •;  $  F  t  :  t'  then  either  there  exists  a  unique  dj  such  that 
•  b  dj  :  and  tP  ■  dj  =  t  or  no  such  substitution  exists. 

This  induction  principle  will  indeed  be  valid. 

We  are  now  ready  to  proceed  with  the  proof  of  the  above  theorem.  As  we  have  mentioned  earlier,  we 
will  carry  out  the  proof  in  a  constructive  manner;  its  computational  content  will  be  a  pattern  matching 
algorithm!  Yet  for  presentation  purposes  we  will  make  a  slight  diversion  from  the  expected  order:  we  will 
present  the  algorithm  first  and  then  proceed  with  the  details  of  the  proof  out  of  which  the  algorithm  is 
extracted. 

Pattern  matching  algorithm.  We  illustrate  the  algorithm  in  Figures  5.10  through  5.12  by  presenting  it 
as  a  set  of  rules.  If  a  derivation  according  to  the  given  rules  is  not  possible,  the  algorithm  returns  failure. 
The  rules  work  on  typing  derivations  for  patterns  and  terms.  The  matching  algorithm  for  terms  accepts 
an  input  substitution  dj,  and  produces  an  output  substitution  dj/.  We  denote  this  as  <o\v  >  dj/.  Most 
of  the  rules  are  straightforward,  though  the  notation  is  heavy.  The  premises  of  each  rule  explicitly  note 
which  terms  need  to  be  syntactically  equal  and  the  recursive  calls  to  pattern  matching  for  sub-derivations. 
In  the  consequence,  we  sometimes  unfold  the  last  step  of  the  derivation  (easily  inferrable  through  typing 
inversion),  so  as  to  assign  names  to  the  various  subterms  involved. 

Of  special  note  are  the  two  rules  for  unification  variables,  which  represent  an  important  case  splitting 
in  the  proof  that  will  follow.  The  essential  reason  why  two  rules  are  needed  is  the  fact  that  patterns  are 
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Ip  t :  tT )  ~  (•;  $  h  t' :  tT)  <  unspec ^ 

[$]  t  :  [$]  tT)  ~  (•  F  [$]  f :  [$]  tT)  >  of, 

(fS>u  Ip  <b,  wf)  ~  (•  h  3>,  <&"  wf)  >  of 
(p&u  I p  [$]  :  [$]  ctx)  ~  (•  h  [$]  <S>"  :  [$]  ctx)  >  of 

Ip  $  wf)  ~  (•  h  $/  wf)  >  <tJ 


fe  * 


•  wf)  ~  (•  F  •  wf)  >  unspec ^ 

(Tm  Ip  $  wf)  ~  (•  F  $'  wf)  >  ay,  (Tk;  $  Ip  t  :  s)  ~  (•;  &  F  t' :  s)  <  of  >  of' 
(f&u  I p  ($,  t)  wf)  ~  (•  h  ($',  t ')  wf)  >  of' 


(^«  hi  <t>i  wf)  ~  (•  F  $,  $'  wf)  >  unspec ^  [i  >-»  [$]  <I>/] 


Figure  5.10:  Pattern  matching  algorithm  for  xHOL,  operating  on  derivations  (1/3) 

allowed  to  be  non-linear :  that  is,  the  same  unification  variable  can  be  used  multiple  times.  This  is  guided 
by  practical  considerations  and  is  an  important  feature  of  our  pattern  matching  support.  Our  formulation 
of  pattern  matching  through  partial  contexts  and  substitutions  allows  such  support  without  significantly 
complicating  our  proofs  compared  to  the  case  where  only  linear  patterns  would  be  allowed.  The  two  rules 
thus  correspond  to  whether  a  unification  variable  is  still  unspecified  or  has  already  been  instantiated  at  a 
previous  occurence.  In  the  former  case,  we  just  need  to  check  that  the  scrutinee  only  uses  variables  from 
the  allowed  prefix  of  the  current  context  (e.g.  when  our  pattern  corresponds  to  closed  terms,  we  check 
to  see  that  the  scrutinee  t 1  does  not  use  any  variables);  if  that  is  the  case,  we  instantiate  the  unification 
variable  as  equal  to  the  scrutinee.  In  the  latter  case  we  only  need  to  check  that  the  already-established 
substitution  for  the  unification  variable  Xi  is  syntactically  equal  to  the  scrutinee. 

Proof  of  pattern  matching  determinism  and  decidability.  Let  us  now  return  to  the  pattern  matching 
theorem  we  set  out  to  prove  in  the  beginning  of  this  section.  First,  we  will  prove  a  couple  of  lemmas 
about  partial  substitution  operations. 

Lemma  5.1.8  (Typing  of  joint  partial  substitutions) 

•  hdJjiTj  •  b  of2 :  T2  T1oT2  =  'F/  TfloTf2  =  of' 

•  h  of'  :  T' 
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$  Ip  t  :  tT)  ~  (•;  h  t' :  t'^  <  >  o^,' 


j  .  j 


7\&  ►  <7\h i 


(^«;  $  Ip  c  :  t)  ~  (•;  h  c  :  t')  <  aq,  >aq,  (Vu;  $  Ip 

L  •  (Jq,  =  L 

(^„;  $  Ip  ^z. :  0  ~  (•;  $'  1“  VLI  :t')<a 

s  =  s*  (^»;  $lp  fi  :s)  ~  (•;  $'  I-  :  s*)  <  3^  >  oj' 

~  (•;  $/>  ^  f^l  |$'| :  K)  <  > 

^  Ip  tl :  5  #;$l"  A,:  s* 

(s,s',s")en  (st,s',s'')e7l  _ 

$lpn(£i).f2:s"  •;  *  * 

^  r^l|$|:f/)  ~  (•;  $/>  I" ^1 1$'! :  *") 


Vui  $tptl:s 
h  ^  r^ij$i :  i 
^;^i?n(t1).Lt/; 


»;  $  1“  t[ :  s* 


1*1+1 


:  s 


•;  $',  t[  h  |  t' 

»;  l-  n(t').  |/ 


:  t 


$'| 
1*1+1 


:  s 


k  ^(fi)-f2 :  n (h)-  l/J  |$|+i  •;  ^  h  Kt[)-t2  ■  n(t|).  [t"\  |$,|+1 


<  <t,j,  >  a-qj 


s  =  s 


relevant  (V M  Ip  $  wf)  =  $  $  Ip  n(tj.t*  :  s)  ~  (•;  $  h  II (t').t'  :  s' )  <  >  a^' 

(**>  ®  ■?  h  ■  n XO-h)  ~  (•; h  K :  n(t>J) <  ^ 

relevant  (V u;  $  \p  ta  :  s)  =  (Vu;  $  I pt2:ta)~  (•;  $'  h  t' :  t')  <  <r^\%  >  5*2 


h  :n(0-4 

^^pWa)-h:s 

Vh>  $ip  h  h'\h 1|*|  •(“**>  *2) 


&  y  t[:n(t'a).t'b 

•;  h  t' :  t' 

.;  I-  :  s' 


*;  ^\-pt[t'2:  \t'y\  |$/|  •  (id&,  t'2) 


<  (Jq,  >  (Jq,  |  o  <Jq,2 


Figure  5.11:  Pattern  matching  algorithm  for  xHOL,  operating  on  derivations  (2/3) 
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$  I pt:tT)~  (•;  &\ -t' :  t'T)  <  ct*  > 


O',! 


$  I ~Pt:  Type )  ~  (•;  $'  b  f :  Type )  <  axV  > 

$1?  T :  0  ~  (•;  ^  1“  t[  ■  ('P„;  $1 pt2:t)~  (•;  b  t' :  f)<dq,'  >df2 


Type 


•;  $  b  t' :  t' 
•;  $  b  t( :  t' 

►;  $  b  t' :  Type 


<  a-q,  >  O  (Jg,  2 


'PK ;  $  Ip  fj  =  12  :  Prop  •;  <t>  b  t'x  =  t'2:  Prop 

Oy-i= ?  'IVz  =  [$*]zT 

('P„;  ^Ip^/a  :tT-a)  ~  (•;  $'b  t' :  4)  ->•  [$*  •  o^]  O 

<5y,.z  =  [$*]  £  £  =  t' 


(^«;  $lp^/0' :  Pr)  ~  (•;  ^b  t'  :tlT)<aq,> 


CTq, 


Figure  5.12:  Pattern  matching  algorithm  for  dHOL,  operating  on  derivations  (3/3) 

Proof.  By  induction  on  the  derivation  of  d\vi  o  o\V2  —  Iff  and  use  of  typing  inversion  for  o\V  ]  and  <fV2. 

□ 

Lemma  5.1.9  (Typing  of  partial  substitution  limitation) 

•  b  of, :  T  •  b  'P/  wf  'P/  C  'P 

Proof.  Trivial  by  induction  on  the  derivation  of  3^U/  =  of,'.  □ 

Let  us  now  proceed  to  the  main  pattern  matching  theorem.  To  prove  it  we  will  assume  well-sortedness 
derivations  are  subderivations  of  normal  typing  derivations.  That  is,  if  T;  $  Ip  t  :  t',  with  t'  f  Type  ,  the 
derivation  T;  $  Ip  t'  :  s  for  a  suitable  s  is  a  sub-derivation  of  the  original  derivation  T;  <P  I j,  t  :  t1 .  The 
way  we  have  stated  the  typing  rules  for  dblOL  this  is  actually  not  true,  but  an  adaptation  where  the  t' :  s 
derivation  becomes  part  of  the  t  :  t'  derivation  is  possible,  thanks  to  Lemma  4.1.7.  Furthermore,  we 
will  use  the  quantifier  3-1  as  a  shorthand  for  either  unique  existence  or  non-existence,  that  is,  3]x.P  = 
(3!x.P)  V  (->3x.P) 

Theorem  5.1.10  (Decidability  and  determinism  of  pattern  matching) 

XV u  Ip  $  wf  •  b  wf  relevant  (T u  \p  $  wf)  = 

1. - — - 

3-IdJ.(  •borJ:T,;(  A  $  •  of,  -  &  j 
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$  Ip  t  :  tT  •;  h  t' :  t'T  relevant  (l! u;  $  Ip  t :  £0  =  V 

^  u;  \p  tT  :  s  A  •;  $  b  £^  :  s  A  relevant  {h  u\  3>  Ip  tT  :  s)  =  vPa  ^ 

V  (  tr  =  Type  A  Ip  $  wf  A  •  h  <I>  wf  A  relevant  (pi!  u  Ip  $  wf)  =  l!  u  ^ 

3!^.(  •  bdJ:'PJ<  A  $-orJ  =  $/  A  tT-of,  =  t’T  ) 

2.  - - - - - - - 

•  bdJ/:T)<  A  $  •  o%'  =  &  A  tT-a^  —  t'r  A  t-o^-t'  ^ 

3  .hfri^  re/eM(^^r:^)=^ 

•hcj^r'I'^  A  T  ■  =  T'  'j 

Proof. 

Part  1  By  induction  on  the  well-formedness  derivation  for  $. 

Case  PCtxExpty. 


V^lp.wf/ 

Trivially,  we  either  have  l>'  =  •,  in  which  case  unspec^,  is  the  unique  substitution  with  the  desired  proper¬ 
ties,  or  no  substitution  possibly  exists. 

Case  PCtxVar. 

/T^lp^wf  Hu;  <Z>\p  t :  s\ 

\  ^„lp($,  t)wf  / 

We  either  have  that  T7  =  t'  or  no  substitution  possibly  exists.  By  induction  hypothesis  get  dy,  such 
that  $  •  oq  =  &  and  •  h  dj  :  l! u  with  =  relevant  (\P(<  Ip  $  wf).  Furthermore  by  typing  inversion 
we  get  that  •;  h  t'  :  s' .  We  need  s'  =  s  otherwise  no  suitable  substitution  exists.  Now  we  use  part 
2  to  either  get  a  o\f  which  is  obviously  the  substitution  that  we  want,  since  (<P,  t)  ■  o\f  =  l>' ,  t'  and 
relevant  ( l! u  Ip  ($,  t)  wf)  =  relevant  (T;<;  $  Ip  t  :  s);  or  we  get  the  fact  that  no  such  substitution  possibly 
exists.  In  that  case,  we  again  conclude  that  no  substitution  for  the  current  case  exists  either,  otherwise  it 
would  violate  the  induction  hypothesis. 

Case  PCtxCVarUnif. 


T(<  Ip  $  wf 


i  >  [vp|  l! u-i  =  [$]  ctx 

<^)wf 


We  either  have  ly'  =  T,  <P//,  or  no  substitution  possibly  exists  (since  $  does  not  depend  on  unifica¬ 
tion  variables,  so  we  always  have  $  •  dj  =  <P).  We  now  consider  the  substitution  oy,  =  unspecxl,  [z  i— > 
[$]  $"].  We  obviously  have  that  ($,  <f>t)  •  dj  =  <P,  l>" ,  and  also  that  •  h  of,  :  l! u  with  T u  =  T;(@z  = 
relevant  (T  Ip  $,  wf).  Thus  this  substitution  has  the  desired  properties. 


Part  2  By  induction  on  the  typing  derivation  for  t . 
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Case  PConstant. 

/  c  :  t  G  £  •;  •  b  tT  :  s  s  ^  Prop  \ 

\  Vu;$\pc:tT  ) 

We  have  t  ■  o\v'  =  c  ■  6\y  =  c.  So  for  any  substitution  to  satisfy  the  desired  properties  we  need  to  have  that 
t1  =  c  also;  if  this  isn’t  so,  no  possibly  exists.  If  we  have  that  t  =  t'  =  c,  then  we  choose  dj'  =  dj  as 
provided  by  assumption,  which  has  the  desired  properties  considering  that: 
relevant  $  ly  c  :  t)  =  relevant  $  ly  tT  :  s)  =  relevant  Ip  $  wf) 

(since  tT  comes  from  the  definitions  context  and  can  therefore  not  contain  extension  variables). 


Case  PVar. 

/$.L  =  tT  tT  :  s  s^Prop\ 

V  ) 

Similarly  as  above.  First,  we  need  t1  =  vLi,  otherwise  no  suitable  o\y  exists.  From  assumption  we  have 
a  unique  dj  for  relevant  ('PM;  $  Ip  tT  :  s).  If  L  ■  dj  =  L! ,  then  dj  has  all  the  desired  properties  for  dj  , 
considering  the  fact  that  relevant  (\Pa;  $  Ip  v L  :  £p)  =  relevant  ('&u  Ip  $  wf)  and  relevant (T;  $  Ip  tT-s)  — 
relevant  (T  ly  <F  wf)  (since  tT  =  <F.z).  It  is  also  unique,  because  an  alternate  dj'  would  violate  the  assumed 
uniqueness  of  o\y.  If  L-a^^L',  no  suitable  substitution  exists,  because  of  the  same  reason. 

Case  PSort. 

/  (*,*')  g  .A  \ 

V^j^lpsrsV 

Entirely  similar  to  the  case  for  PCONSTANT. 


Case  PIIType. 


h  F^Vi  :s'  ( s,s',s")en\ 


$l p^{tx).t2:  s'- 


) 


First,  we  have  either  that  t'  =  II( £').£',  or  no  suitable  avl/  exists.  Thus  by  inversion  for  t'  we  get: 

$'  Ip  t[ :  y,  t[  \ p  [ t']  |$/|  :  s',  (s„  s',  s")  G  K. 

Now,  we  need  s  =  s*,  otherwise  no  suitable  dj/  possibly  exists.  To  see  why  this  is  so,  assume  that  a  o\y 
satisfying  the  necessary  conditions  exists,  and  s  ^  sp,  then  we  have  that  £j  •  o\y  =  £',  which  means  that 
their  types  should  also  match,  a  contradiction. 

We  use  the  induction  hypothesis  for  t]  and  t'.  We  are  allowed  to  do  so  because 
relevant  (\PK;  $  ly  s"  :  s//x)  =  relevant  $  ly  s  :  s//x/) 
and  the  other  properties  for  dj  also  hold  trivially. 

From  that  we  either  get  a  dj/  such  that:  •  b  dj/ :  \F'  ,  t]  ■  dj/  =  £',  $  •  o^,  =  for 
db  =  relevant  (T;<;  $  ly  t1  :  s);  or  that  no  such  substitution  exists.  Since  a  partial  substitution  unifying  t 
with  t'  will  also  include  a  substitution  that  only  has  to  do  with  \F'  ,  we  see  that  if  no  dj/  is  returned  by 
the  induction  hypothesis,  no  suitable  substitution  for  t  and  t'  actually  exists. 
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We  can  now  use  the  induction  hypothesis  for  t2  and  by/  with  such  that: 

—  relevant  u',  $,  tx  Ip  f  t2l|$|  :  d)  •  The  induction  hypothesis  is  applicable  since 
relevant  $,  tj  Ip  s' :  s//x//)  =  relevant  (Ta;  $  Ip  t1  :  s) 

and  the  other  requirements  trivially  hold.  Especially  for  s'  and  s'  being  equal,  this  is  trivial  since  both 
need  to  be  equal  to  s"  (because  of  the  form  of  our  rule  set  1Z). 

From  that  we  either  get  a  d\^"  such  that  •  b  cP^"  :  T",  |"t2"l|$| '  ^ '  ~  \ |$/|>  ^ '  d\y"  =  ^  and  h  '  d\y"  = 

or  that  such  d^,"  does  not  exist.  In  the  second  case  we  proceed  as  above,  so  we  focus  in  the  first  case. 

By  use  of  properties  of  freshening  we  can  deduce  that  (II(t1).t2)  •  d^"  =  !!(£'). (t'),  so  the  returned  d^"  has 

the  desired  properties,  if  we  consider  the  fact  that 

relevant  u;  $  Ip  n(£j).£2  :  s")  =  relevant  ('P u;  <P,  tx  Ip  \t2]^  :  s')  = 


Case  PIIIntro. 


t(<;  h :s  Ta;  hk  t(<;  $lpn(£1).[£3j 


J|$|+i 


:  s 


^  ip  Kh)-1!  '■  n(d)-  L^3J|$i+i 


s'  ^  Prop\ 

) 


We  have  that  either  t'  =  \(t'^).t^,  or  no  suitable  axl/  exists.  Thus  by  typing  inversion  for  l'  we  get: 

•;  Ip  t[ :  s„  •;  t[  \p  \ t'2]  |$/|  :  t'y  •;  Ip  n(t{).  L?3J|$'|+i  :  V 


By  assumption  we  have  that  there  exists  a  unique  such  that  •  h  dj  :  <b-dj  =  (II(£1).  |_%J)‘dJ  = 

n(^)-  I/3J  ,  T  relevant  (Ta;  P  Ip  Ilfo).  L%J|$|+i)  =  From  these  we  also  get  that  s'  —  s'. 

From  the  fact  that  (n(£j).  L ^3 J ) ' =  II(£|).  J  ,  we  get  first  of  all  that  t1-d^  =  t'v  and  also  that  £3-oq)  =  £3. 
Furthermore,  we  have  that  relevant  (T;  $  Ip  n(t1).  [t3J  :  s')  =  relevant  (T;  $,  tx  Ip  £3 :  s'). 

From  that  we  understand  that  dj  is  a  suitable  substitution  to  use  for  the  induction  hypothesis  for  [ t2]. 
Thus  from  induction  hypothesis  we  either  get  a  unique  by/  with  the  properties: 

•  \  £2]  •  d^/  =  |"  >  ($,  h)  ■  d^  =  t[,  t3  ■  d^  =  ty  if 

relevant  H\  3>,  tx  Ip  f £2]|$|  :  £3)  =  or  that  no  such  substitution  exists.  We  focus  on  the  first  case;  in 
the  second  case  no  unifying  substitution  for  t  and  t '  exists,  otherwise  the  lack  of  existence  of  a  suitable 
dij/  would  lead  to  a  contradiction. 

This  substitution  b\J)  has  the  desired  properties  with  respect  to  matching  of  t  against  t'  (again  using  the 
properties  of  freshening),  and  it  is  unique,  because  the  existence  of  an  alternate  substitution  with  the  same 
properties  would  violate  the  uniqueness  assumption  of  the  substitution  returned  by  induction  hypothesis. 


Case  PIIElim. 


T T;<;  $\pll(ta).tb  :s 


T(<;  ^  Ip  tl  t1:\tb\m-{id^t2) 


^  Prop  ^ 


Again  we  have  that  either  t'  =  t'{  t'2,  or  no  suitable  substitution  possibly  exists.  Thus  by  inversion  of 
typing  for  t '  we  get: 

•;  $  Ip  £j  :  n  {ta)-ty,  ^  I p  t2:  ta,  tT  —  \t^\  |$,|  •  t2 ) 

Furthermore  we  have  that  $  Ip  II(£^).£^  :  s  and  •;  $  Ip  11(d). £'  :  s'  for  suitable  s,  s'.  We  need  s  =  s', 
otherwise  no  suitable  d\v'  exists  (because  if  £,  and  t'{  were  matchable  by  substitution,  their  Il-types  would 
match,  and  also  their  sorts,  which  is  a  contradiction). 
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We  can  use  the  induction  hypothesis  for  II (q).q,  and  II (t').t',  with  the  partial  substitution  oq,  limited 
only  to  those  variables  relevant  in  dq  Ip  $  wf.  That  is,  if  =  relevant  (dq;  $  Ip  II(q).q,  :  s)  then  we 
use  the  substitution  dqH  .In  that  case  all  of  the  requirements  for  dq,  hold  (the  uniqueness  condition  also 
holds  for  this  substitution,  using  part  1  for  the  fact  that  $  and  db  only  have  a  unique  matching  substi¬ 
tution),  so  we  get  from  the  induction  hypothesis  either  a  dq/  such  that  •  b  dq/  :  dq(  d>  •  dq  =  <t>f  and 
(n(ta).tfr)-Oy  =  II (t').t' ,  or  that  no  such  dq/  exists.  In  the  second  case,  again  we  can  show  that  no  suitable 
substitution  for  t  and  t'  exists;  so  we  focus  in  the  first  case. 

We  can  now  use  the  induction  hypothesis  for  q,  using  this  dq/.  From  that,  we  get  that  either  a  dq;,  exists 
for  dq  =  relevant  (dl u ;  $  Ip  q  :  n(q).q)  such  that  q  ■  dq,j  =  or  that  no  such  dqij  exists,  in  which  case 
we  argue  that  no  global  dq/  exists  for  matching  t  with  t'  (because  we  could  limit  it  to  the  dq  variables  and 
yield  a  contradiction). 

We  now  form  =  dq/|j„  for  dA  =  relevant  (dq  d>  I Ip  q  :  q).  For  dq//  we  have  that  •  Ip  dq,^  :  d///, 
$  •  dqi"  =  d>7  and  ta  ■  dql  =  ta .  Also  it  is  the  unique  substitution  with  those  properties,  otherwise  the 
induction  hypothesis  for  ta  would  be  violated. 

Using  we  can  allude  to  the  induction  hypothesis  for  t2,  which  either  yields  a  substitution  dq)2  for 
dq  =  relevant  (dq  d>  Ip  t2  :  q),  such  that  t2  ■  dq,2  =  t'2,  or  that  no  such  substitution  exists,  which  we  prove 
implies  no  global  matching  substitution  exists. 

Having  now  the  dqij  and  dq)2  specified  above,  we  consider  the  substitution  o\v .  =  dq, ,  o  dq,2.  This  substi¬ 
tution,  if  it  exists,  has  the  desired  properties:  we  have  that 
dq.  =  relevant  (dq,;  $  I pt1t2:\tb]-  (id$,  t2))  = 

=  relevant  (dq  $  I p  q  :  II (q).q)  o  relevant  (dq  $  I j>  t2:  q) 
and  thus  •  b  dq)r  :  dq.  Also,  (q  t2)  •  dqr  =  t'x  t'2,  tT  ■  dq,r  =  t'T,  and  $  •  dq,r  =  d>/  It  is  also  unique:  if 
another  substitution  had  the  same  properties,  we  could  limit  it  to  either  the  relevant  variables  for  q  or  t2 
and  get  a  contradiction.  Thus  this  is  the  desired  substitution. 

If  dq)  does  not  exist,  then  no  suitable  substitution  for  unifying  t  and  t’  exists.  This  is  again  because 
we  could  limit  any  potential  such  substitution  to  two  parts,  dqy|  and  dq,2  (for  dq  and  dq  respectively), 
violating  the  uniqueness  of  the  substitutions  yielded  by  the  induction  hypotheses. 

Case  PEqType. 

/  ^  h>  ^  h- h 

V  ^u-,$\pt1  =  t2-.Prop  ) 

Similarly  as  above.  First  assume  that  t1  =  (q/  =  t'),  with  t[  :  t' ,  t'  :  t'  and  t '  :  Type.  Then,  by  induction 
hypothesis  get  a  matching  substitution  dq,  for  ta  and  t' .  Use  that  dq>  in  order  to  allude  to  the  induction 
hypothesis  for  t]  and  t2  independently,  yielding  substitutions  dqij  and  dq,2.  Last,  claim  that  the  globally 
required  substitution  must  actually  be  equal  to  dqr  =  dqjj  o  dq2. 

Case  PMetaVarUnif. 

f'S>u.i  =  T  T=[$Jtr  (i>  |^|=0)  dq;$l p(?:%  C  $  a -id, $  ^ 

\  ^u^^pXj/a  :tT-a  y 

We  trivially  have  tT  ■  a  =  tT.  We  split  cases  depending  on  whether  dq.z  is  unspecified  or  not. 
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If  <5\[;.z  =?,  then  we  split  cases  further  depending  on  whether  t'  uses  any  variables  higher  than  |dy  •  o\\\  —  1 
or  not.  That  is,  if  t '  <■  |d>,  •  o\v\  or  not.  In  the  case  where  this  does  not  hold,  it  is  obvious  that  there 
is  no  possible  d^  such  that  {XJa)  ■  crj/  =  t' ,  since  oj'  must  include  dj,  and  the  term  {XJa)  ■  d^  can 
therefore  not  include  variables  outside  the  prefix  dy  •  dj  of  $  •  dj.  In  the  case  where  t'  <f  jdy  •  d^|,  we 
consider  the  substitution  oj'  =  d^[i  >-»•  [d>^  •  dy,]  t'~\.  In  that  case  we  obviously  have  $  •  dj/  =  db,  tT  ■ 
oj'  =  tT,  and  also  t  ■  dj  =  t' .  Also,  db  =  relevant  (d^;  $  Ip  XJa  :  tp  ■  a)  =  { relevant  (Ta;  d>*  ip  tT  :  s))  o 
relevant (T;  $  ip  a  :  d>  J  o  (T@z). 

We  need  to  show  that  •  b  dj/ :  db.  First,  we  have  that  relevant  (T;  $  ip  a  :  d>*)  =  relevant  (\P  Ip  d>  wf)  since 
d>*  C  d>.  Second,  we  have  that  relevant (T;  $  Ip  tT  :  s)  = 

{relevant  (T(<;  d>#  Ip  tT  :  s))  o  relevant  (T  Ip  d>  wf).  Thus  we  have  that  T/  =  T  o  (T@z).  It  is  now  trivial  to 
see  that  indeed  •  b  dj :  db. 

If  d\I;.z  =  t  „,  then  we  split  cases  on  whether  t  ,  =  t'  or  not.  If  it  is,  then  obviously  o\v  is  the  desired  unifying 
substitution  for  which  all  the  desired  properties  hold.  If  it  is  not,  then  no  substitution  with  the  desired 
properties  possibly  exists,  because  it  would  violate  the  uniqueness  assumption  for  oj. 

Part  3  By  inversion  on  the  typing  for  T . 

Case  PExtCtxTerm. 

V  ^ u  Ip  [$]  1  '■  [^]  lT  / 

By  inversion  of  typing  for  T’  we  have:  T  =  [d>]  t1,  •;  $  Ip  t’ :  tT,  •;  $  Ip  tT  :  s. 

We  thus  have  d^  =  relevant  (d/ u;  $  Ip  tT  :  s)  =  unspec ^  (since  $  is  also  well-formed  in  the  empty  ex¬ 
tension  context),  and  the  substitution  dj  =  unspec ^  is  the  unique  substitution  such  that  •  b  dj  : 
d>  •  dj  =  d>  and  tr  ■  dj  =  tT.  We  can  thus  use  part  2  for  attempting  a  match  between  t  and  t1,  yield¬ 
ing  a  d^/  such  that  •  b  dj/  :  db  with  db  =  relevant  (T  u;  $  Ip  t  :  tp)  and  t  ■  dj7  =  t' .  We  have  that 
relevant  (xSt u;  $  bp  t  :  tT)  =  relevant  (d^  Ip  T  :  K) ,  thus  db  =  d>  by  assumption.  From  that  we  realize  that 
dj  is  a  fully-specified  substitution  since  •  b  o~J  :  T,  and  thus  this  is  the  substitution  with  the  desired 
properties. 

If  unification  between  t  and  t'  fails,  it  is  trivial  to  see  that  no  substitution  with  the  desired  substitution 
exists,  otherwise  it  would  lead  directly  to  a  contradiction. 

Case  PExtCtxInst. 

/  Ip  $,  wf  \ 

W*  Ip  [$]  $/;  [$]ctxj 

By  inversion  of  typing  for  T '  we  have:  T'  =  [d>]  $>" ,  •  Ip  d>,  d>x/  wf,  •  Ip  $  wf.  From  part  1  we  get  a  dj 
that  matches  d>,  db  with  d>,  db',  or  the  fact  that  no  such  dj  exists.  In  the  first  case,  as  above,  it  is  easy  to 
see  that  this  is  the  fully-specified  substitution  that  we  desire.  In  the  second  case,  no  suitable  substitution 
exists. 

□ 
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The  above  proof  is  constructive.  Its  computational  content  is  a  pattern  matching  algorithm  for  pat¬ 
terns  and  closed  terms  -  the  algorithm  we  presented  earlier.  Notice  that  the  rules  presented  in  Figures  5.10 
through  5.12  follow  the  inductive  structure  of  the  proof  and  make  the  same  assumption  about  types-of- 
types  being  subderivations.  Based  on  the  statement  of  the  above  theorem,  it  is  evident  that  this  algorithm 
is  sound  (that  is,  if  it  finds  a  substitution,  that  substitution  will  be  a  matching  substitution),  and  that  it  is 
also  complete:  if  a  matching  substitution  exists,  then  the  algorithm  will  find  it.  The  formal  statement  of 
soundness  and  completeness  is  as  follows. 

Lemma  5.1.11  (Pattern  matching  algorithm  soundness  and  completeness) 

u  Ip  $  wf  •  b  wf  relevant  u  \p  $  wf)  = 

(T;<  Ip  $  wf)  ~  (•  h  <&'  wf)  >  dj 

•  b  dj  :  T(<  $  •  dj  = 

Ip  $  wf  •  b  3b  wf  relevant  u  Ip  $  wf)  = 

3d^.(  •  b  of, :  T(<  $  •  dj  =  ) 

2. - — - 

(T(<  Ip  $  wf)  ~  (•  b  3b  wf)  >  ay 

3>  I j,  t  :  tT  •;  3>;  b  t' :  tf  relevant  u;  $  Ip  t :  tf)  =  3^ 

(  *;$b  t'T:s  relevant^  u;  <$>lp  tT  :  s)  =$u 

V  (  tT  =  Type  Ip  3>  wf  •  b  §  wf  relevant  (3^  Ip  $  wf)  =  T 

•  b  dj  :  $  •  dy  =  tT-dy  =  t'T 

$  I pt:tT)~  (•;  b  t' :  t')  <  dj  >  dy' 

3. - — - 

•  b  dy' :  3^  $  •  of,'  =  tT  ■  of,'  =  t'T  t-a^'=t' 

3^;  3>  I j,  t  :  tT  •;  3>;  b  t' :  t'T  relevant  $  I j,  t :  tf)  =  3^ 

(  ^u'^'rPtT-s  »;$b  t'T:s  relevant^ u;  $\p  tT  :  s)  =$ u  ) 

V  ^  tr  =  Type  Ip  3>  wf  •  b  $  wf  relevant  (T  u  Ip  $  wf)  =  ^ 

•  b  dj  :  $  •  dy  =  tT-dy  =  t'T 

ddj^  •  b  dy' :  3b  $  •  dy'  =  $'  tT-af,'  =  t'T  t-ofj  —  t'  ) 

/j.  _ Z _ t _ 

(3^;  $  I jt:tT)~  (•;  b  t' :  tf')  <  dj  >  dy 

*u\-pT:K  .b  T',K  relevant^  uVpT,K)=Tlu 

5  _ (VudpT:K)~(.dT':K)»^ _ 

•b(t$:f8  T  ■  ay  =  T' 

V^pT-.K  •  b  T'  :K  relevant  (V  uVpT  ,K)  =  3>  „ 

3dJ.(  •bc7^:T„  T  ■  =  T'  ) 

6'  (T^r:if)~(.br:^)>dJ 

Proof.  Valid  by  construction.  □ 
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( Annotated  terms ) 


{Annotated  contexts)  <F4 
{Annotated  extension  terms)  TA 


c\s\vL\b,\X{tf).tA\Us{tf).tA\{tf:tA:s)tA 
t?=tA  tA\Xi/a 
•  |  $A,  (L4  :  5)  |  $A,  <]>t 


Figure  5.13:  Annotated  dHOL  terms  (syntax) 

Practical  pattern  matching.  We  can  significantly  simplify  the  presentation  of  the  algorithm  if  instead 
of  working  directly  on  typing  derivations  we  work  on  annotated  terms  which  we  will  define  shortly. 
We  will  not  do  this  only  for  presentation  purposes  but  for  efficiency  considerations  too:  the  algorithm 
described  so  far  would  require  us  to  keep  full  typing  derivations  at  runtime.  Instead,  we  will  extract  the 
information  required  by  the  algorithm  from  the  typing  derivations  and  make  them  available  syntactically 
at  the  level  of  terms.  The  result  will  be  the  new  notion  of  annotated  terms  and  an  alternative  formulation 
of  the  algorithm  that  works  directly  on  such  terms. 

We  present  the  syntax  of  annotated  terms  and  annotated  contexts  in  Figure  5.13.  The  main  changes 
are: 

1 .  the  inclusion  of  sort  information  in  II-types, 

2.  type  and  sort  information  for  functions  in  function  application  and 

3.  type  information  for  the  equality  type. 

Furthermore,  each  member  of  the  context  is  annotated  with  its  sort.  Last,  annotated  extension  terms  do 
not  need  the  context  information  anymore  -  that  information  is  only  relevant  for  typing  purposes.  We 
adapt  the  pattern  matching  rules  so  that  they  work  on  annotated  terms  instead  in  Figure  5.14.  The  algo¬ 
rithm  accepts  ^ u  as  an  implicit  argument  in  order  to  know  what  the  length  of  the  resulting  substitution 
needs  to  be. 

A  well-typed  annotated  term  tA  is  straightforward  to  produce  from  a  typing  derivation  of  a  normal 
term  t;  the  inverse  is  also  true.  In  the  rest,  we  will  thus  use  the  two  kinds  of  terms  interchangeably  and 
drop  the  A  superscript  when  it  is  clear  from  context  which  kind  we  mean.  For  example,  we  will  use  the 
algorithm  of  Figure  5.14  algorithm  directly  to  decide  pattern  matching  between  a  well-typed  pattern  t  and 
a  scrutinee  t' .  It  is  understood  that  these  have  been  converted  to  annotated  terms  after  typing  as  needed. 
We  give  the  exact  rules  for  the  conversion  in  Figure  5.15  as  a  type  derivation-directed  translation  function. 

We  prove  the  following  lemma  about  the  correspondence  between  the  two  algorithms  working  on 
derivations  and  annotated  terms;  then  soundness  and  completeness  for  the  new  algorithm  follows  directly. 

Lemma  5.1.12  (Correspondence  between  pattern  matching  algorithms) 

(T,^r:A)~(.hr/:A)>^  ^  T  :KJA  =  TA  [.  h  T':KjA  =  T'A 

l^u\-T  :K]a  =  Ta  [«F  T':KJA  =  T,a  Ta  ~  TA  >  d^A 

33^.(  \*\-a^:^u^A  =  a^A  (tyu  Ip  T  :K)  ~  (•  h  T':K)  ) 
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T  ~  T  >  ay  | 

<&'  ~  <&"  >  o\y 

~  <£"  >  Oy  I 


t  ~  t'  <  unspecq,  >  <rj 

H*  ~ 


•  ~  •  >  unspecq, 


s  =  s'  $~$/>5rJ  t  ~  t'  <  >  cr^ 

($,  (t  :5))~(^',  (i/:5/))>^/ 


($,  <^>-)  ~  vunspec^  \i  >->  [— ]  <&'] 


t  ~  t'  <a^ 


C~C<(Jg>>C7)j, 


5  ~  5  <1  <T  ,j>  >  (7,j, 


/ 


5  =  5 


?j~t1<lC71j,>(Jv[,  [  t2l  ~  |"t9"|<I(Jv[,  >(J^, 

us(h)-h  ~  ns'(0-f2  <  ^  >  ^ 


L  ■  <j^j  —  L 

vL~  v'L<Oy>(J^ 

\h\  ~\t!?\<c^i>c^l' 


5  —  5  t  t  ^  (J  vjy  (7  ^ 

^l~^l<I£r'I <  l>cr'I'l  ^2  ~  ^2  ^  ^  °"'I'2  °  <J']>2  =  ‘Ff 

((tj :  t  :  5)  12)  ~  ((t'  :  t'  :  5')  t')  <  dj  >  dj" 


t  ~  t  < 1  <T,j,  >  (T^ 


~  <  cj^  > 


~  ^  ^  ^vp  ^  °\p2 


(7 , 


°  0"\T/  T  —  C7\T 


\]>1  w  ^  ^2 


Cvp-Z 


;  =? 


(fl  =^2)~(<=t'<) 

t'  <f  \a  •  3\p| 


<  (J^j  >  0\j> 


(Tty'l  —  t 


XJa~  t' <<jy>ory[i  -*■  [-]  t'] 


XJa  ~  t' <a^>a\ 


Figure  5.14:  Pattern  matching  algorithm  for  /HOI.,  operating  on  annotated  terms 
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l*\-T:K]A  =  TA 

$  h  t  :  trJA  =  tA  [tfhS,  &wfJA  =  $A, 

l*  [*]  t  :  [$]  tj]A  =  [-]  tA  [tf  h  [$]  $' :  [$]  rtx]  ^  =  [-] 

[['ll  b  $  wf] 7'  =  $A  [['F;  $  h  £  :  s]]"4  =  tA  [[\F  h  <F  wfj"4  =  <F4 

I-  •  wfj  A  =  •  [^|-($,  t)wf|/1  =  ($j4,  (tA:s))  [^h$,  (f)t  wf]]/l  =  ($j4,  (f>i) 

[tf;  $h  t:t'JA  =  tA 

1^;  $l~c  :  tJA  =  c  ['F;  $  Ip  5  :s'J  =  5  E^;^l ~pVL:tJA=vL 

1^;  h  :slA  =  t?  [^;  h^>  rf2l|$|  :s'JA=  \ti1 

[*;  «  H  t, :  ^  =  t}  [*;  i,  I,  h  r>2l|«| :  t'l  ^  =  [ hY 

[*;  -f  i-  Kh)-h  ■  n((,).  I/J  m+,]'  = 

^;$hti:n {ta).tbJA  =  tA  l*;$\-t2:tJA  =  tA  |\P;  $  \~  U(ta).tb  :  sJA  =  tA 
[^;  $  h  hh  ■  \  h\*\ '  («*#>  *2)]  A  =  (tf:tA:  s )  tA 

Pv  ^  E^d  *  h  :  t]-4  =  tA  py  $  Ip  t2  :  tf4  =  ^ 

^'rPh  =  t2:  PropJA  =  (if  =ri  tA) 

lVu^\-pXllo:tT.at  =  XJo 
Figure  5.15:  Conversion  of  typing  derivations  to  annotated  terms 
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(f$!  u  Ip  $  wfj  ~  (•  b  ze^)  >  <tJ  [['P,,  b  $  z^"4  =  <L4  [[•  b  $/  ze^J]  ^  =  &A 

3'  ^M^y1 

p^bSzejffl^fc*  l»\-$'wflA  =  &A  $A  ~  $M  = 

35^.(  [[•h^:^f(]]/1>^  (^„ip^v)~(»i-^/^y)>^;  ) 

(^„;  $  I-  t  :  tr)  ~  (•;  $'  h  t' :  ty)  <  >  d\f 

t:trJA  =  tA  [•;  &  \~  t' :  t'TJA  =  t,A  [•  b  dj  :  $] A  =  o^A 

tA  ~  t/A  <  OqA  >  [[•  h  of,' :  & J  A 

l^u;  $\-t:tTJA  =  tA 

[[•;  $'b  t' :  Jpj"4  =  t'A  [•  h  dj  :  A  =  df,A  tA  ~  t'A  <df,A>df,'A 
3dJ.(  [•horJ/:$/J/1>aJ//l  ('Pa;  $  b  t  :  tT)  ~  (•;  b  t' :  ty)  <  d^  >d^'  ) 

Proof.  By  structural  induction  on  the  derivation  of  the  pattern  matching  result.  We  also  need  to  use 
Lemma  5.1.1.  □ 

Lemma  5.1.13  (Soundness  and  completeness  for  practical  pattern  matching  algorithm) 

yH\-pT:K  [[^h  T:K]A  =  TA 

•  h  T’-.K  [.b  T':KjA  =  T'A  relevant  (fZ  lt\-p  T  :K)=^U  T~T'»aA 

3<M  »b  <t9:Vh  [[•!-  <riSl-VHJA  =  <T$  T-a^  =  T'  ) 

*H\pT:K 

[[^h  T:KJa  =  Ta  «b  T-.K  [•  h  T  :KjA  =  T'a  relevant  (Vh  \p  T  :K)=Vh 

3<t^.(  •  h  T-ay  =  T'  ) 

T  ~  T  >  [[•  h  cry  :  'Pj^4 

Proof.  By  combining  Lemma  5.1.11,  Lemma  5.1.12  and  Lemma  5.1.1.  □ 


Summary 

Let  us  briefly  summarize  the  results  of  this  section.  For  the  typing  judgement  we  defined  in  the  end  of 
Section  5.1,  as  follows: 

\P  ip  \Pa  wf  \F,  IF,*  i pTp:K  unspec ^ ,  \PW  Q  relevant  (fl1,  \P„  ip  TP  :  if) 

*t*p*u>TP:K 
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we  have  the  following  results: 

'hi *Vh>Tp:K 

-  Substitution  lemma 

>  Tp  ■  <jy  :  K  ■  <jy 

Tp  '-K  »\-  T  :K  Pattern  matching 

q<l„  (  m  V-  rr  ■  vl/  T  rr  —  T  \  DETERMINISM  AND  DECIDABILITY 

u>  Tp  '-K  »\~  T  :K  TP  ~  T  =  pattern  matching 

a\-  rr  ■  \h  T  .rr  —T  ALGORITHM  SOUNDNESS 

u>Tp:K  »\~T  :K 

3°Y-(  •  h  cry  :  Tp  ■  aq  =  T  )  Pattern  matching 

T  ^  T  —  rr  ALGORITHM  COMPLETENESS 

1  p  ~  1  —  <7,j, 

5.2  Collapsing  extension  variables 

Let  us  consider  the  following  situation.  We  are  writing  a  tactic  such  as  the  simplify  tactic  given  in  Sec¬ 
tion  2.3  under  the  heading  “Staging”,  a  sketch  of  which  is  (using  the  new  notations  for  extension  types): 

simplify  :  ( cf> :  ctx)  —*  (P  :  \cf>]Prop)  —*■  (Q  :  [(f)]  Prop,  [(f)]  P  D  Q  A  Q  D  P) 

simplify  P  =  match  P  with 

QARdO  (QdRdO,--) 

In  order  to  fill  the  missing  proof  object  (denoted  as  •••),  we  need  to  perform  pattern  matching  on  its 
inferred  type:  the  open  proposition 

[(f)]  ((QRRdO)d(QdRdO))R((QdRdO)d(QARd  O)) 

in  the  extension  context  'L  that  includes  S,  P,  Q,  R,  O.  Yet  the  pattern  matching  procedure  presented 
in  the  previous  section  is  only  applicable  when  the  extension  context  is  empty.  Instead  of  changing  our 
pattern  matching  procedure,  we  notice  that  we  can  prove  an  equivalent  first-order  lemma  instead  where 
only  normal  logical  variables  are  used  (and  is  therefore  closed  with  respect  to  'L): 

[P  :  Prop,  Q  :  Prop,  R  :  Prop,  O  :  Prop]  ((Q  A  P  D  O)  D  (Q  D  R  D  O))  A  ((Q  D  R  D  O)  D  (Q  A  P  D  O)) 

Then,  by  instantiating  this  lemma  with  the  variables  of  the  open  T  at  hand,  we  can  get  a  proof  of  the 
desired  type.  But  is  there  always  such  an  equivalent  first-order  lemma  in  the  general  case  of  extension 
contexts  T  and  can  we  find  it  if  one  exists?  This  will  be  the  subject  of  this  section. 

More  formally,  we  want  to  produce  a  proof  object  for  a  proposition  P  at  a  point  where  the  extension 
variables  context  is  T.  If  we  want  to  discover  this  proof  object  programmatically,  we  need  to  proceed 
by  pattern  matching  on  P  (as  the  scrutinee).  A  problem  arises:  P  is  not  closed,  so  the  pattern  matching 
methodology  presented  in  the  previous  section  does  not  apply  -  since  only  patterns  are  allowed  to  use 
extension  variables  (as  unification  variables).  That  is,  we  need  to  solve  the  following  problem: 
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If  T,  H  Ip  Pp  :  [4>]  Prop  and  T  b  P  :  [4>]  Prop , 
then  there  exists  a ^  such  that  T  h  :  (T,  'h(()  and  Pp-  a^  =  P. 

This  is  a  significantly  more  complicated  pattern  matching  problem,  because  P  also  contains  meta-variables. 
To  solve  it  properly,  we  need  to  be  able  to  have  unification  variables  that  match  against  meta-variables; 
these  unification  variables  will  then  be  meta-2-variables. 

In  this  section  we  will  partially  address  this  issue  in  a  different  way.  We  will  show  that  under  certain 
restrictions  about  the  current  non-empty  extension  context  T  and  its  usage,  we  can  collapse  terms  from 
T  to  an  empty  extension  context.  A  substitution  exists  that  then  transforms  the  collapsed  terms  into 
terms  of  the  original  4/  context.  That  is,  we  can  get  an  equivalent  term  that  is  closed  with  respect  to  the 
extension  context  and  use  our  normal  pattern  matching  procedure  on  that. 

We  will  thus  prove  the  following  theorem  for  contextual  terms: 

T;  $  h  t  :  t'  collapsable  (T  b  [4>]  t  :  [4>]  t ') 

•;  h  tj :  4/;  4>  b  a  :  4>j  tj  •  a  =  t  t'^-a  =  t'  ) 

Combined  with  the  pattern  matching  algorithm  given  in  the  previous  section,  which  applies  when  T  =  #, 
this  will  give  us  a  way  to  perform  pattern  matching  even  when  T  is  not  empty  under  the  restrictions  that 
we  will  express  as  the  “collapsable”  operation. 

Let  us  now  see  the  details  of  the  limitations  in  the  applicability  of  our  solution.  Intuitively,  we  will 
be  able  to  collapse  the  extension  variable  context  when  all  extension  variables  depend  on  contexts  $ 
which  are  prefixes  of  some  4>'  context.  The  collapsable  operation  is  actually  a  function  that  discovers 
such  a  context,  if  it  exists.  Furthermore,  all  uses  of  extension  variables  should  be  used  only  with  identity 
substitutions.  This  restriction  exists  because  there  is  no  generic  way  of  encoding  the  equalities  that  are 
produced  by  non-identity  substitutions.  We  present  the  full  details  of  the  collapsable  function  in  Figures 
5.16  and  5.17. 

The  actual  collapsing  transformation  amounts  to  replacing  all  instances  of  meta-variables  with  normal 
variables,  instantiating  all  context  variables  with  the  empty  context,  and  renaming  normal  variables  ap¬ 
propriately,  so  that  both  meta-variables  and  normal  variables  can  refer  to  one  identical  $  context.  We  can 
define  this  transformation  through  a  series  of  substitutions  and  meta-substitutions.  Before  we  proceed  to 
see  the  details  of  the  proof  through  which  the  transformation  is  defined,  we  need  two  auxiliary  lemmas. 

Lemma  5.2.1 

collapsable (4>)  <  4>;  >  <&"  collapsable (T  b  [4>]  t  :  [$]  tT)  >  4b 

1. -  2. - 

(  Tc$  $"  =  $  )  v  (  $,,  =  $/  ) 

collapsable (T  b  [4>0]  :  [4>0]  4^)  >  4>; 

3. - 

$0,$i  C$' 


Proof.  By  structural  induction  on  the  derivation  of  collapsable (•). 


□ 
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collapsable  ('&)<)$>  <t>7 

collapsable  ('&)  <  $  >  collapsable  (K )  < 

collapsable  (•)<$>$  collapsable  ('ll ,  K )  <  $  > 

collapsable  ( K )  < 

T  —  [<£]  t  collapsable  ( T)  <  $>'  >  $"  collapsable  ($)  <  >  <&” 

collapsable  ( [$]  t )  <  collapsable ( [$]  ctx )  <  ^ 

collapsable  ( T)  <  >  3>" 

collapsable ($)<$' >$"  collapsable collapsable ($ v 

collapsable ([$]  t)  <  collapsable ([$x\  <J>2)  <  &  > 

collapsable  ($hT  :  K )  > 

collapsable  ('P)  <  •  >  $;  collapsable ( K )  <  &  >  <&"  collapsable  ( T)  < 

collapsable  (f  h  T  :  K )  >  $>" 

collapsable  ('&  b  $  wf)  >  & 

collapsable  ('F)  <  •  >  collapsable  ($)  < 

collapsable  ('F  h  4>  wf)  >  <S>" 

Figure  5.16:  Operation  to  decide  whether  dHOL  terms  are  collapsable  with  respect  to  the  extension 
context 
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collapsable  (<£•)  <  $;  >  <&" 

collapsable^)  ><&"  $  =  collapsable (t)  <  $ 

collapsable (•)<$' >&  collapsable ($,  t ) 

collapsable  ($)  <  $  C  collapsable  ( t )  <  <&"  collapsable  ($)  < 

collapsable ($,  t)<$/>$,/  collapsable (<£,  ^>-)<$/>($,  (f>-) 

collapsable ($)  <  $  C 

collapsable  ($,  ^  •)  <  &  > 

collapsable  (t)  <1  & 


collapsable (s)  <  $'  collapsable (c)  <  collapsable ( vL )  <  9 

collapsable (t1)<i$/  collapsable (t2)  <  $'  collapsable (i1)<i$/  collapsable (t7) 

collapsable (d(tj).t,)  <  <ft'  collapsable (I\.{t1).t2)  <  & 

collapsable (t1)<i$/  collapsable (t2)  <  &  collapsable (i1)<i$/  collapsable (t7)  <& 


collapsable (t1  t2)  <  & 


collapsable (tl  =  t2)  < 


a  C  id^ 


collapsable  (X-  /a)  < 


Figure  5.17:  Operation  to  decide  whether  dHOL  terms  are  collapsable  with  respect  to  the  extension 
context  (continued) 
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Lemma  5.2.2 


collapsable  (T)  <  •  >  $ 
collapsable ('L)  <  $;  > 


collapsable  ( K )  <  •  >  $  $  C  cjd 

collapsable  ( K )  <  ^ 


collapsable  ( T)  <  •  >  $ 
collapsable  (T)  < 


collapsable ($0)  <•><!>  $  C 

4. - 

collapsable  ($0)  < 


Proof.  By  structural  induction  on  the  derivation  of  collapsable (■).  □ 

We  are  now  ready  to  state  and  prove  the  main  result  of  this  section.  Both  the  statement  and  proof  are 
technically  involved,  so  we  will  give  a  high-level  picture  prior  to  the  actual  proof.  The  main  theorem  that 
we  will  use  later  is  a  simple  corollary  of  this  result. 

Theorem  5.2.3 

h  T  wf  collapsable (T)  <  •  >  <1>0 

1  2  ,*.1  1  —1  inv 

dW  ,(J  . 

T1  huvJ,:T  •hn^:T1  T1  h  'h1  wf  T1;  $1  h  a1  :  $°  •  T1;  $°  •  a*  h  a~x : 

al-a-l  =  id^,ai  T;  $°  F  <riav  :  Q1  •  Vt.tf;  $°  h  t  :  f  ^  t  ■  ■  a1  ■  ■  a,nv  =  t 

Vre$1.(T  =  [^]fArc$1) 


Explanation  of  involved  terms.  The  main  idea  of  the  proof  is  to  maintain  a  number  of  substitu¬ 
tions  to  transform  a  term  from  the  extension  context  T  to  the  empty  context,  by  a  series  of  context 
changes.  We  assume  that  the  collapsable  operation  has  established  that  all  extension  variables  depend 
on  prefixes  of  the  context  T0.  For  example,  this  operation  will  determine  <h°  for  the  extension  context 
T  =  cf>  :  ctx,A  :  \cf>]Nat,B  :  \cf>,  x  :  Nat]  Nat,  T  :  \<f]  Type,  t  :  \_f]  T  to  be  <h°  =  (f>,  x°  :  Nat.  Then,  the 
substitutions  and  contexts  defined  by  the  theorem  are: 

is  a  context  that  is  composed  of  ‘collapsed’  versions  of  all  extension  variables,  as  well  as  any  normal 
variables  required  to  type  them.  For  the  above  example,  this  would  be  determined  as  3?1  =  A1  :  Nat,  x1  : 
Nat,  B 1  : Nat,  T 1  :  Type,  £ 1  :  T 1 . 

T 1  is  an  extension  context  where  all  extension  variables  depend  on  the  T 1  context.  It  has  the  same 
metavariables  as  T,  with  the  difference  that  all  of  them  use  prefixes  of  the  T1  context  and  dependencies  on 
previous  meta-variables  are  changed  to  dependencies  on  the  T1  context.  Context  variables  are  also  elided. 
For  the  above  example  context  we  will  therefore  have  T1  =  A!  :  [4?1]  Nat,B' :  [3?1]  Nat,  T1 :  [‘h1]  Type,  t' : 
[T1]  T1,  where  we  use  primed  names  for  meta-variables  to  distinguish  them  from  the  normal  ones  of  T. 

can  be  understood  as  a  renaming  of  metavariables  from  the  original  T  context  to  the  T 1  context.  Since 
the  two  contexts  have  essentially  the  same  metavariables,  the  renaming  is  simple  to  carry  out.  Context 
variables  are  substituted  with  the  empty  context.  This  is  fine  since  parametric  contexts  carry  no  informa¬ 
tion.  For  the  example  context  above,  we  will  have  that  =  cf>  »,A  >-*■  A' ,B  <->  B',T  >-*■  T ,  t  >-*  t' 
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a 1  can  be  understood  as  a  permutation  from  variables  in  <5°  to  variables  in  $ 1 .  The  need  for  it  arises  from 
the  fact  that  collapsed  versions  of  metavariables  get  interspersed  with  normal  variables  in  d?1.  a~l  is  the 
permutation  for  the  inverse  direction,  that  is  from  variables  in  to  variables  in  d>°.  For  the  example,  we 
have: 

a1  =  x°  >-*■  x1 

o'-1  = A 1  >— >  A' ,  x 1 1— »■  x°,  51  <— >  B',  Tl  i— >  T' ,  tl  i— »■  t7 

a2  carries  out  the  last  step,  which  is  to  replace  the  extension  variables  from  T1  with  their  collapsed  ver¬ 
sions  in  the  $1  context.  In  the  example,  we  would  have  that  a2  =  A'  >->  [ddJA1,  B'  >->■  [d?1].#1,  T 
[Vjr1,  t'  ^[i1]  t\ 

atnv  is  the  substitution  that  inverses  all  the  others,  yielding  a  term  in  the  original  T  extension  context 
from  a  closed  collapsed  term.  In  the  example  this  would  be  ainv  =  A1  A,  x1  >-*■  x°,  Bx  >-*■  B,  T1  >->■ 
T,  t 1  t. 


Proof.  By  induction  on  the  derivation  of  the  relation  collapsable (T)  <  •  >  d>°. 

Case  T  =  •.  We  choose  T1  =  •;  =  cr2  =  •;  d?1  =  •;  a1  =  a-1  =  •;  oinv  =  •  T 1  =  •  and  the  desired 

trivially  hold. 


Case  T  =  T7,  [d>]  ctx.  From  the  collapsable  relation,  we  get:  collapsable  (T7)  <*>d>70,  collapsable  ( [d>]  ctx)< 
d>70  >  d>°.  By  induction  hypothesis  for  T7,  get: 


n  /-i 
a  ■  a 


•  F42:T71 


T  h  $  1  wf 


T71;  $71  h 


—  id^/o  a 


T7;  $70  h  a'mv  :  $71  •  a,72 


n71:$/0.< 


71  hff7-1:^1 


T71; 


=  t 


Vi.T7;  $70b  f.t'  -- 
VTGf71.r  =  [r]tArc$71 
By  inversion  of  typing  for  [d>]  ctx  we  get  that  T7  b  T  wf. 

We  fix  <jy  =  [d>70  •  a^]  •  which  is  a  valid  choice  as  long  as  we  select  T1  so  that  T71  C  T1.  This 

substitution  has  correct  type  by  taking  into  account  the  substitution  lemma  for  <I>70  and  a[y . 

For  choosing  the  rest,  we  proceed  by  induction  on  the  derivation  of  d>70  C  d>°. 


If  $°  =  $70  then: 

We  have  $  C  d>70  because  of  Lemma  5.2.1. 

Choose  T1  =  T71  ;  n2  =  a'f  ;  $1  =  $71;  a1  =  a'1  ;  a”1  =  o'~\  ainv  =  a'inv. 

Everything  holds  trivially,  other  than  axj;  typing.  This  too  is  easy  to  prove  by  taking  into  account  the 
substitution  lemma  for  $  and  Also,  a'mv  typing  uses  extension  variable  weakening.  Last,  for  the 
cancellation  part,  terms  that  are  typed  under  T  are  also  typed  under  T7  so  this  part  is  trivial  too. 


If  T°  =  d>7°,  t  then:  (here  we  abuse  notation  slightly  by  identifying  the  context  and  substitutions  from 
induction  hypothesis  with  the  ones  we  already  have:  their  properties  are  the  same  for  the  new  <I>70) 

We  have  $  =  d>°  =  d>70,  t  because  of  Lemma  5.2.1  (d>°  is  not  d>70  thus  d>°  =  d>). 

First,  choose  d>!  =  d>71,  i  ■  a7'  •  a71.  This  is  a  valid  choice,  because  T7;  d>70  h  t  :  s;  by  applying  a7,1  we  get 
T71;  d>70  •  <jy  b  t  ■  <j^  :  s;  by  applying  an  we  get  T71;  d>71  h  t  ■  a ^  ■  an  \  s. 

Thus  T71  h  $71,  t  ■  ■  an  wf. 

Now,  choose  T 1  =  T71 ,  [dy]  t  ■  ■  an.  This  is  well-formed  because  of  what  we  proved  above  about  the 

substituted  t,  taking  weakening  into  account.  Also,  the  condition  for  the  contexts  in  T1  being  subcontexts 
of  d?1  obviously  holds. 
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Choose  a%  =  [$i]  iwi|.  We  have  •  h  a2  :  h'1  directly  by  our  construction. 


Choose  a 1  =  a 


l<C| 


w  \ 

.  We  have  that  this  latter  term  can  be  typed  as: 


'F1;  3?1  h  t;|$/i|  :  t  ■  ■  a'1,  and  thus 

Choose  ^_1  —  "'~x 


have  'F1;  t  ■  an 


a 


Choose  ainv  =  a 


a  ,  ana  tnus  we 

a"  y  zwo_/i,.  The  desired  properties  obviously  hold. 

tinv 


^l$/0|,  which  is  typed  correctly  since  t  •  <r^  •  u71  •  a, 
Last,  assume  'F;  <F70,  t  h  t+ :  t' .  We  prove  C  •  ui  •  a1  •  a2  •  a1”*’  =  A- 


First,  t,  is  also  typed  under  lF7  because  t  ,  cannot  use  the  newly-introduced  variable  directly  (even  in 
the  case  where  it  would  be  part  of  Fc,  there’s  still  no  extension  variable  that  has  in  its  context). 


Thus  it  suffices  to  prove  t*  ■  ■  a1  ■  ■  ainv  =  t*. 

Then  proceed  by  structural  induction  on  A-  The  only  interesting  case  occurs  when  t,  =  V\ 
which  case  we  have: 


|$'°| 


in 


a^-atnv  =  v^o  nyal-al  • 


oU1V  ~  V\$n\  '  ’  °lnV  ~  V\$n-al\  '  ~  V\&a\ 


If  <F°  =  <F70,  <f>i  then: 

By  well-formedness  inversion  we  get  that  \F.z  =  [<ly]  ctx,  and  by  repeated  inversions  of  the  collapsable 
relation  we  get  <fy  C  <F70. 


Choose  ‘F1  =  <F71  ;  fF1  =  'F/1  ;  =  o'f;  a1  =  an;  a  1  =  o'  1;  ainv  =  a 


Unv 


Most  desiderata  are  trivial.  For  a1,  note  that  (<F71,  <f>-)  =  <F71  •  a71  since  by  construction  we  have  that 


o\7 


always  substitutes  parametric  contexts  by  the  empty  context. 


For  substitutions  cancellation,  we  need  to  prove  that  for  all  t  such  that  \F;  <F,  &i  h  tt  :  tf  we  have 
-al-ainv  =  A-  This  is  proved  directly  by  noticing  that  t  ,  is  typed  also  under  \F7  (cf>  •  as  the 
just-introduced  variable  cannot  refer  to  itself). 


Case  VF  =  'F7,  [$]  t.  From  the  collapsable  relation,  we  get: 
collapsable  ('F7)  <  •  >  <F70,  collapsable (<F)  <  <F70  >  <F°,  collapsable (t)  <  <F°. 
By  induction  hypothesis  for  lF7,  we  get: 


iF 


/l  /- 1 
a  •  a 


r  $  1  wf 


.ha;2:*71 

=  id# o.ffn  \F7;  $70  h  alinv  :  $71  •  a.7,2 


'F71;  $71  b  a71 :  $70  •  a71 


'F71;  :$71 

/I  /I  /2  /in?;  , 

■  Cp  •  O’  •  **  •  O'  =  * 


Va'F7;  $70bt  :t7: 
VrG'F71.r=[$*]tA$*C$71 
Also  from  typing  inversion  we  get:  \F7  b  $  wf  and  lF7;  $bt:s. 

We  proceed  similarly  as  in  the  previous  case,  by  induction  on  <F70  C  <F°,  in  order  to  redefine  \F71,  a^, 
a'\  a'~\  atnv 


a 


with  the  same  properties  but  for  <F°  instead  of  <F70: 


\F 


'’b.;^7 

n  /- 1 
a  ■  a 


•b<2:$71 


'F  1  b  <F  wf 


'F71:  $71b, 


./ 1 


'F7;  $°  b 


JlYlV 


a 


-,n 
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'F71;  $°-a 


71  b  a7"1 :  $71 


Vi.'F7;  $°bf:t7^A  u,7T!  •  n71  •  a,72  •  a'inv  =  t 


•V 


VTGr.r  =  [r]fArc$7 


Now  we  have  $  C  $°  thus  'F7;  $c  b  t  :  s. 

By  applying  a ^  and  then  n71  to  t  we  get  'F71;  $71  b  t  ■  ■  an  :  s.  We  can  now  choose  =  <F71,  t  ■  ■  an. 

Choose  'F1  =  'F71,  n71.  It  is  obviously  well-formed. 

Choose  <7^  =  u^1,  [$]  t1.  We  need  'F1;  $  •  b  tl :  t  ■  a 

Assuming  tl  =X^n^/ a,  we  need  t  ■  ■  an  ■  a  =  t  ■  and  'F1;  $  •  b  a  :  $b 

Therefore  a  =  a7-1  and  cr^  =  a^,  [$]  X^n^l a'~x  with  the  desirable  properties. 

Choose  =  <r(2,  v^ny  We  trivially  have  •  b  n2  :  'F1. 
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Choose  a1  =  an  ,  with  typing  holding  obviously. 

Choose  a-x=a~\  X^/id^.  Since  a1  does  not  use  the  newly  introduced  variable  in  T 1 ,  the  fact  that 
n-1  is  its  inverse  follows  trivially. 

Choose  <jmv  =  aHnv ,  id{<&).  This  is  well-typed  if  we  consider  the  substitutions  cancellation  fact. 

It  remains  to  prove  that  for  all  such  that  T',  [4>]  t;  h  :  C,  we  have  £*  •  •  a1  ■  ■  ainv  =  t *. 

This  is  done  by  structural  induction  on  t,,  with  the  interesting  case  being  t,  =  X^^/a*.  By  inversion  of 
collapsable  relation,  we  get  that  a *  =  id§. 

Thus  (X^/id#)  •  4  •  n1  •  a'  •  atnv  =  (X^n]/(id^  ■  a*))  •  a1  ■  ■  atnv  =  {X^liid^ i ))  •  a1  ■  ■  ainv  = 

{X^l{id^-ax))-al-atnv  ={X^/{id^))-al-ainv  =  {v^ny{id^-al))-ainv  =  {v^nyid^_a2)-ainv  = 
v\$n.al\  •<jinv  =X]p’\lid$.  □ 

Theorem  5.2.4 


T  h  [<1>]  t  :  [4>]  tr  collapsable (T  b  [<£]  t :  [$]  tT)  >  <!>* 

33b,  t1,  t'T,  a. 

•  h  <$>' wf  •  b  [3>x]  t' :  [3b]  t'y  3/;  3>  b  a  :  3b  t'  ■  a  =  t  t'T  ■  a  =  tT 

Proof.  Trivial  application  of  Theorem  5.2.3.  Set  3b  =  3>!  •  a^,  t/ =  t  ■  ■  a1  ■  a^,  t'T  =  tT  ■  ■  a1  ■  a^, 

and  also  set  n  =  n-1.  □ 
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Chapter  6 

The  VeriML  computational  language 


Having  presented  the  details  of  the  dHOL  logic  and  its  associated  operations  in  the  previous  chapters,  we 
are  now  ready  to  define  the  core  VeriML  computational  language.  I  will  first  present  the  basic  constructs 
of  the  language  for  introducing  and  manipulating  dHOL  logical  terms.  I  will  state  the  type  safety  theorem 
for  this  language  and  prove  it  using  the  standard  syntactic  approach  of  Wright  and  Felleisen  [1994],  I  will 
then  present  some  extensions  to  the  language  that  will  be  useful  for  the  applications  of  VeriML  we  will 
consider  in  the  rest. 

6.1  Base  computation  language 

6.1.1  Presentation  and  formal  definition 

The  core  of  VeriML  is  a  functional  language  with  call-by-value  semantics  and  support  for  side-effects  such 
as  mutable  references  in  the  style  of  ML.  This  core  calculus  is  extended  with  constructs  that  are  tailored  to 
working  with  terms  of  the  dHOL  logic.  Specifically,  we  include  constructs  in  order  to  be  able  to  introduce 
extension  terms  T  -  that  is,  contextual  terms  and  contexts  -  and  also  to  look  into  their  structure  through 
pattern  matching.  The  type  K  of  an  extension  term  T  is  retained  at  the  level  of  VeriML  computational 
types.  Types  K  can  mention  variables  from  the  extension  context  T  and  can  therefore  depend  on  terms 
that  were  introduced  earlier.  Thus  dHOL  constructs  available  at  the  VeriML  level  are  dependently  typed. 
We  will  see  more  details  of  this  in  the  rest  of  this  section. 

Let  us  now  present  the  formal  details  of  VeriML,  split  into  the  ML  core  and  the  dHOL-related  exten¬ 
sions.  Figure  6.1  defines  the  syntax  of  the  ML  core  of  VeriML;  Figures  6.3  through  6.5  give  the  relevant 
typing  rules  and  Figure  6.8  gives  the  small-step  operational  semantics.  This  ML  core  supports  the  follow¬ 
ing  features:  higher-order  functional  programming  (through  function  types  r]  —*■  t2);  general  recursion 
(through  the  fixpoint  construct  fix  %  :  r.e);  algebraic  data  types  (combining  product  types  Tj  X  r2,  sum 
types  T]  +  t2,  recursive  types  ua  :  k.r  and  the  unit  type  unit);  mutable  references  ref  r;  polymorphism 
over  types  supporting  full  System  F  -  also  referred  to  as  rank-N-polymorphism  (through  the  Va  :  k.r 
type);  and  type  constructors  in  the  style  of  System  F0J  (by  including  arrows  at  the  kind  level  kx  — >  k2  and 
type  constructors  Xa  :  k.r  at  the  type  level).  Data  type  definitions  of  the  form: 

data  list  a  =  Nil  |  Cons  of  a  x  list  a 

can  be  desugared  to  their  equivalent  using  the  base  algebraic  data  type  formers: 
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{Kinds) 

{Types) 

{Expressions) 


{Contexts) 
{ Values) 
{Evaluation  contexts) 


{Stores) 
{Store  typing ) 


k  ::=  *\  k  k 

r  ::=  unit  |  t1  — *  r2  \  r1  X  r2  \  r1  +  r2  \  pec :  k.r  |  ref  r 
|  Vcr :  k.r  |  Xa  :  k.r  \t1t1\  a 
e  ::=  ()  |  Xx  :  r.e  \  e  e'  \  x  \  {e,  e')  |  proj  ■  e  |  inj  ■  e 

|  case(e,  x.e' x.e")  |  fold  e  \  unfold  e  \  ref  e  \  e  :=  e'  \  \e 
|  /  |  Aa  :  k.e  \  e  t  |  fix  x  :  r.e 
T  ::=  •  |  T,  x  :  r  |  T,  a  :  k 

v  ::=  ()  |  Xx  :  r.e  \  {v,  v')  \  inj  ■  v  \  fold  v  \  l  \  Aa  :  k.e 
£  ::=  •  |  £  e'  \  v  £  \  {£,  e)  \  {v,  £)  \  proj;  £  \  inj^  £ 

|  case(£,  x.e1,  x.e2)  |  fold  £  |  unfold  £  |  ref  £  |  £  :=  e' 

\  v  :=  £  \  \£  \  £  r 
p  ::=  •  |  p,  l  —+v 
A4  ::=  •  |  Ai,  l  :  r 


Figure  6.1:  VeriML  computational  language:  ML  core  (syntax) 


{Kinds)  k 
{Types)  t 
{Expressions)  e 

{ Values)  v 
{Evaluation  contexts)  £ 


•  ••  |n  v -K.k 

■■■  \{V  :K)->t\{V  :K)xt\XV  :K.t\tT 

...\XV:K.e\eT\(T,e){V:K)xr 

let  (  V,  x  )  =  e  in  e' 

holmatch  T  return  V  :  K.r  with  'L U.T'  ►  e' 
...\XV:K.e\(T,e){V:K)XT 
...\£T\{T,£){V:K)xr\\et(V,x)  =  £\ne' 


Figure  6.2:  VeriML  computational  language:  /HOL-related  constructs  (syntax) 

let  list  =  Xa  :  ★./dist :  *.unit  +  a  x  list 
let  Nil  =  Xa  :  *.fold  (inj x  ()) 

let  Cons  =  Xa  :  *./lhd  :  a.Xtl :  list  or.fold  (inj2  (hd,  tl)) 

We  do  not  present  features  such  as  exception  handling  and  the  module  system  available  in  Standard  ML 
[Milner,  1997],  but  these  are  straightforward  to  add  using  the  standard  mechanisms.  Typing  derivations 
are  of  the  form  T;  Ai;  F  h  J,  where  T  is  a  yet-unused  extension  variables  context  that  will  be  used  in 
the  /HOL-related  extensions;  Ai  is  the  store  typing,  i.e.  a  context  assigning  types  to  locations  in  the 
current  store  p;  and  F  is  the  context  of  computational  variables,  including  type-level  a  and  expression- 
level  %  variables.  The  operational  semantics  work  on  machine  states  of  the  form  (  p  ,  e  )  which  bundle  the 
current  store  p  with  the  current  expression  e.  We  formulate  the  semantics  through  evaluation  contexts  £ 
[Felleisen  and  Hieb,  1992],  All  of  these  definitions  are  entirely  standard  [e.g.  Pierce,  2002]  so  we  will  not 
comment  further  on  them. 

The  new  /HOL-related  constructs  are  dependently-typed  tuples  over  /HOL  extension  terms,  depen- 
dently-typed  functions,  dependent  pattern  matching  and  type  constructors  dependent  on  /HOL  terms. 
We  present  their  details  in  Figures  6.2  (syntax),  6.6  and  6.7  (typing)  and  6.9  (operational  semantics).  We 
will  now  briefly  discuss  these  constructs. 
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\P  h  k  wf 


h  \P  wf 

- CKnd-CType 

\P  h  *  wf 


f;  Thr:^ 


- CTyp-Unit 

\P;  T  h  unit :  ★ 


'I';  r  h  Ti  :  *  f;  rhT2:* 

- - —  CTyp-Prod 

\P;  T  h  Tj  X  t2  :  ★ 


\P  h  k  wf  \P  h  k  wf 

- - - CKnd-Arrow 

\P  h  k  — *  k  wf 


\P;rhTj:*  \P;rhT2:* 

- = —  CTyp-Arrow 

\P;  T  h  Tj  — »  t2  :  * 


f;  Thii  :*  'f/;n_T2:* 

- CTyp-Sum 

\P;  T  h  Tj  +  t2  :  * 


\P  h  k  wf  'P;  T,  a  :  k  h  t  :  k 

- CTyp-Rec 

\P;  T  h  (^or :  &.t)  :  k 


\P;  r  h  t  :  * 

- CTyp-Ref 

\P;  r  h  ref  t  :  * 


'P  h  k  wf  \P;  T,  or :  k  h  t  :  ★ 

- CTyp-Poly 

\P;  T  h  (Vor :  &.t)  :  * 


'P  h  k  wf  'P;  T,  a :  k  h  t  :  k' 
'P;  T  h  (/lor :  &.t)  :  k  — *  k' 


CTyp-Lam 


'P;  T  h  Tj :  k  — *■  k'  'P;  T  h  t2  :  k 

'P;  T  h  Tj  t2  :  k' 


CTyp-App 


(or :  k)  E  T 

- CTyp-Var 

'P;  T  h  a  :  k 


'P  h  r  wf 


- CCTX-EMPTY 

'P  h  •  wf 


'PhTwf  'PjTh&wf 

- CCTx-TVar 

'P  h  (r,  or :  k)  wf 


'PhTwf  \P;  T  h  t  :  * 

- CCTx-CVar 

'P  h  (r,  %  :  t)  wf 


Figure  6.3:  VeriML  computational  language:  ML  core  (typing,  1/3) 
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b  A4  wf 


b  •  wf 


Store-Empty 


b  A4  wf  •;  •  b  r  :  * 
b  (A4,  l :  t) 


Store-Loc 


\E;  A4;  T  b  e  :  t 


CExp-Unit 


\E;  A4;  T,  %  :  r  b  e  :  r 


\E;  M;  TbQ:  unit 
'E;  A4;  Y  b  e  :  r  — *■  r  'E;  A4;  rbebr 


'E;  A4;  T  b  Ax  :  r.e  : 


CExp-FunI 


:  t  — ►  t 


CExp-FunE 


(x :  t)  e  r 


\E;A4;rbee  :r  f;  Tbx  :r 

'E;  A4;  Y  b  el  :  rl  'E;  A4;  T  b  e2  :  t2 


CExp-Var 


'E;  M;  Y  b  (e1,  e2) :  t1  x  t2 


CExp-ProdI 


'E;  A4;  T  b  e  :  r1  x  t2  z  =  1  or  2 


CExp-ProdE 


'E;  A4;  Y  b  e  :  t-  z  =  1  or  2 


'E;  A4;  Y  b  proj;  e  :  r-  'E;  A4;  T  b  inj  •  e  :  Tj  +  r2 

'E;  A4;  T  b  e  :  rx  +  r2  'E;  A4;  T,  x  :  r1  b  e1  :  r  'E;  A4;  Y,  x  :  r,  b  e,  :  r 


CExp-SumI 


'E;  A4;  Y  b  case(e,  x.ev  x.e2 ) :  t 

'E;  T  b  (^or :  k.r) :  *  'E;  A4;  Y  b  e  :  r[fua  :  k.r /a] 

'E;  A4;  Y  b  fold  e  :  /ua  :  k.r 

'E;  T  b  (fua  :  k.r) :  *  'E;  A4;  Y  b  e  :  \ja  :  k.r 


CExp-SumE 


CExp-RecI 


'E;  A4;  T  b  unfold  e  :  r[/ua  :  k.r /a] 


CExp-RecE 


'E;  A4;  T,  a  :  k  b  e  :  r  'E;  A4;  Y  b  e  :  Yia  :  k.r  f;  Tbr:^ 

CExp-PolyI  - - - CExp-PolyE 


'E;  A4;  T  b  A  a  :  k.e  :  Ilor :  k.r 


'E;  A4;  Y  b  e  r  :  t[t / a] 


Figure  6.4:  VeriML  computational  language:  ML  core  (typing,  2/3) 
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CExp-NewRef 


\E;  M.;  T  h  e  :  ref  r  \E;  M.;  T  h  e' :  r 
\E;  M;  T\~e:=e':  unit 


CExp-Assign 


\E;  M.;  Their 


\E;  M.;  Their 


\E;  A4;  T  h  ref  e  :  ref  r 


'E;  M.;  T  h  e  :  ref  r 

- CExp-Deref 

'E;  A4;  T  He  :  r 


'E;  A4;  Their  t—qt 

- - — - —  CExp-Conv 

'E;  A4;  T  h  e  :  x 


(l  :  r)G  M 

- CExp-Loc 

'E;  M.;  T  h  /  :  ref  r 

'E;  A4;  T,  x  :  r  h  e  :  r 

- : - CExp-Fix 

'E;  A4;  T  h  fix  %  :  r.e  :  r 


Figure  6.5:  VeriML  computational  language:  ML  core  (typing,  3/3) 


\E  h  k  wf 


h  \E,  V  :  K  wf  'E,  V  :  K  h  k  wf 

- CKnd-IIHol 

'Ehny  i/ejfewf 


'E;  T  h  r  :  k 


'E,  V  Thr  :* 

- CTyp-IIHol 

'E;  Th(V 

%  V:K;T  \~r:k 

- CTyp-LamHol 

\E;  T  h  (XV  :  K.t)  :  (II V  :  K.k) 


'E,  V:K;  Thr  :* 

- CTyp-EHol 

'E;  Th(V:^xr:  + 

'E;Thr:n  V  :K.k  V\~T:K 

- CTyp-AppHol 

'E;  Thr  T  :k[T/V] 


Figure  6.6:  VeriML  computational  language:  /HOL-related  constructs  (typing) 
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'F;  A4;  Their 


%  V:K;  M;T  heir 

- CExp-IIHolI 

'T;  M;  T  h  (XV -K.e) :  ((V  :K)  -*•  r) 


'F;  M;  The  VhT:K 

- CExp-IIHolE 

'T;  7W;  The  T  :r[T/V] 

T  h  (V  :  K)  x  t  :  +  VhT:K  \F;  M;  The:  r[T /V] 

- CExp-EHolI 

*;M;r\-(T,e){V:K)XT:((V:K)xT) 

'T;  M;TYe:(V  :K)xr  'F,  V  :  K;  M;  T,  x  :  r  h  e' :  r 

f;  Thr  :* 

- - - - - CExp-EHolE 

\F;  A4;  T  h  let  (  V,  x  )  =  e  in  e  :  r; 


'ThT 

Vi^Thr:*  ^^>7},:^  fr,  M;  T  h  e' :  r[TP/V] 

T  ,  .  holmatch  T  return  V  :  K. r 
'T;A^;Th  .  ,  T  „  ,  irTT/Vl  +  unit 

with  'F  Tp  i-^-e  l  /  j  ' 


CExp-HolMatch 


'Y;  Y  Y  (/ua  :  k.r) :  k  'F;_M;rhe:r[/ua:  k.r /a]  ala2  •  ■  ■  an 

\F;  M.;  Y  h  fold  e  :  (/ua  :  k.r )  •  •  •  an 

\F;  T  h  (/ua  :  k.r) :  k  \F;  A4;  Y  h  e  :  (/ua  :  k.r) a1  a2  ■■■<*„ 

\F;  M. ;  T  h  unfold  e  :  r[/ua  :  k.r/a\  a1a2  ■  ■  ■  an 


at  =  rt  or  Tt 

- CExp-RecI 

a,  =  Tj  or  T- 

— - - - -  CExp-RecE 


Figure  6.7:  VeriML  computational  language:  dHOL-related  constructs  (typing,  continued) 
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Op-Beta 


o,  e) — >(/j,  e') 

(fu,e)  — »  (  y!  ,  e  )  (£  /  •) 

- — - — —  Op-Env  - 

{[j.,  £[e])  — >(y  ,  £[e])  (  y  , (Ax  :  r.e)  v)  — ►  (  y ,  e[v/x\  ) 


(  y .  Proj^i,  v2)) 


- -  Op-Proj 

(  ^  ^  ) 


Op-Case 


( y  ,  case(inj-  v,  x.ev  x.e2 ) )  — *■  ( y  ,  e^\y  I  A) 

-‘(i  y) 


( y  ,  unfold  (fold  v) )  — ►  ( y  ,  v  ) 

l  >  _  E  y 
(y,l:=v) — >(y[l  -+v]  ,  ()) 


Op-Unfold 


Op-Assign 


(y,refv) — >((y,  l) 

l  >-*  v  e  /j 


Op-NewRef 


(/“.!/) — *((*>  v) 


Op-Deref 


( y  ,  (Act :  k.e)  r  )  — >■  ( y ,  e[r/or] ) 


Op-PolyInst 


(  y ,  fix  x  :  r.e  )  — ►  (  y  ,  e  [fix  %  :  r.e/x]  ) 


Op-Fix 


^17  :=^] 

//  ■ — >-  '^’/)[/  :=  =  fj\l  :=  v],  l' i-*  v' 

(y,  l  v')\l  :=  v~\  = 


(l  ^  v)E  y 

(l  >->v)  E  (y,  l  >-*■  v) 

(l>-*-v)  E  ([J.,  l'  <-*■  v')  ■<=  (/  !-►  v)  E  y 


Figure  6.8:  VeriML  computational  language:  ML  core  (semantics) 


(y,e) — >(y,ef) 


- Op-IIHol-Beta 

(y,(AV:K.e)T)—+(y,e[T/V]) 


- - — - - - - - -  Op-SHol-Unpack 

(/j,  let  (  V,  x)  =  {T,  v)  ine  )  — ►  ( y ,  (e  [T /V])[v  /  x]) 


Tp  ~  T  —  (j-q, 

- - — - - - -  Op-HolMatch 

( y  ,  holmatch  T  with  \P U.TP  e  )  — ►  ( y  ,  injj  ( e  ■  ) 


TP~  T  =  fail 

- - - Op-HolNoMatch 

(  y  ,  holmatch  T  with  \PM.Tp  e  )  — ►  (  y  ,  inj2  () ) 


Figure  6.9:  VeriML  computational  language:  /iHOL-related  constructs  (semantics) 
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Dependent  kHOL  tuples.  We  use  tuples  over  /HOL  extension  terms  in  order  to  incorporate  such 
terms  inside  our  computational  language  expressions.  These  tuples  are  composed  from  a  /HOL  part  T 
and  a  computational  part  e.  We  write  them  as  (  T,  e }.  The  type  that  VeriML  assigns  to  such  tuples 
includes  the  typing  information  coming  from  the  logic.  We  will  denote  their  type  as  K  X  r  for  the  time 
being,  with  K  being  the  /HOI.  type  of  T  and  t  being  the  type  of  e.  The  simplest  case  occurs  when 
the  computational  part  is  empty  -  more  accurately  when  it  is  equal  to  the  unit  expression  that  carries  no 
information  ( e  =  ()).  In  this  case,  a  /HOL  tuple  simply  gives  us  a  way  to  create  a  VeriML  computational 
value  v  out  of  a  /HOL  extension  term  T,  for  example: 

v  —  { [P  :  Prop ]  Ax  :  P.x,  () }  :  ([P  :  Prop ]  P  —*■  P)x  unit 

Note  that  this  construct  works  over  extension  terms  T,  not  normal  logical  terms  t,  thus  the  use  of  the 
contextual  term  inside  v.  Consider  now  the  case  where  the  computational  part  e  of  a  /HOL  tuple  (  T,  e  ) 
is  non-empty  and  more  specifically  is  another  /HOL.  tuple,  for  example: 

v  —  ( [P  :  Prop ]  P  — *■  P,  ( [P  :  Prop ]  Ax  :  P.x,  () ) } 

What  type  should  this  value  have?  Again  using  informal  syntax,  one  possible  type  could  be: 

v  =  ( [P  :  Prop ]  P  —*■  P,  ( [P  :  Prop ]  Ax  :  P.x,  () ) } 

:  ( [P  :  Prop ]  Prop )  x  ( [P  :  Prop ]  P  — »  P)  X  u nit 

While  this  is  a  valid  type,  it  is  perhaps  not  capturing  our  intention:  if  we  view  the  value  v  as  a  package 
of  a  proposition  P  together  with  its  proof  n,  the  fact  that  n  actually  proves  the  proposition  P  and  not 
some  other  proposition  is  lost  using  this  type.  We  say  that  the  tuple  is  dependent :  the  type  of  its  second 
component  depends  on  the  value  of  the  first  component.  Thus  the  actual  syntax  for  the  type  of  /HOL. 
tuples  given  in  Figure  6.2  is  (V  :  K)  x  r,  where  the  variable  V  can  be  used  to  refer  to  the  value  of  the  first 
component  inside  the  type  r.  The  example  would  thus  be  typed  as: 

v  —  (  [P  :  Prop ]  P  — ►  P,  (  [P  :  Prop]  Ax  :  P.x,  () } } 

:  (X  :  [P  :  Prop ]  Prop )  x  ( [P  :  Prop]  X)  x  u nit 

We  could  also  use  dependent  tuples  to  create  a  value  that  packages  together  the  variable  context  that  the 
proposition  depends  on  as  well,  by  using  the  other  kind  of  extension  terms  -  contexts: 

v  =  (  [P  :  Prop],  (  [P  :  Prop]  P  — »  P,  (  [P  :  Prop]  Ax  :  P.x,  () } } } 

:  (<f> :  ctx)  x  ( X  :  [(f)] Prop)  x  ([(f>]X)  x  unit 

We  have  only  seen  the  introduction  form  of  dependent  tuples.  The  elimination  form  is  the  binding 
construct  let  (  V,  x  )  =  e  in  e'  that  simply  makes  the  two  components  available  in  e' .  Combined  with 
the  normal  ML  features,  we  can  thus  write  functions  that  create  /HOL.  terms  at  runtime  -  whose  exact 
value  is  only  decided  dynamically.  An  illustratory  example  is  a  function  that  takes  a  proposition  P  and  a 
number  n  as  arguments  and  produces  a  conjunction  P  A  P  A  •  •  •  A  P  of  length  2n .  In  the  rest,  the  /HOL. 
terms  that  we  will  be  most  interested  in  producing  dynamically  will  be  proof  objects. 

conjN  :  (([] Prop)  X  unit)  — *■  int  — *■  (([] Prop)  X  unit) 

=  /!%:(([]  Prop)  x  unit). An  :  int. 

if  n  =  0  then  p 

else  let  (P,  _}  =  %  in  conjN  (  []P  AP,  () )  (n  —  1) 
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Let  us  now  see  the  formal  details  of  the  dependent  tuples.  The  actual  syntax  that  we  use  is  (  T,  e  )  f  \/-A')  x  ~ 
where  the  return  type  of  the  tuple  is  explicitly  noted;  this  is  because  there  are  multiple  valid  types  for  tu¬ 
ples  as  our  example  above  shows.  We  usually  elide  the  annotation  when  it  can  be  easily  inferred  from 
context.  The  type  ( V  :  K )  x  r  introduces  a  bound  variable  V  that  can  be  used  inside  r  as  the  kinding 
rule  CTyp-EHol  in  Figure  6.6  shows.  The  typing  rule  for  introducing  a  dependent  tuple  CExp-EHolI 
in  Figure  6.7  uses  the  dHOL  typing  judgement  T  b  T  :  K  in  order  to  type-check  the  first  component. 
Thus  the  dHOL  type  checker  is  embedded  within  the  type  checker  of  VeriML.  Furthermore  it  captures  the 
fact  that  typing  for  the  second  component  e  of  the  tuple  depends  on  the  value  T  of  the  first  through  the 
substitution  oy,  =  idx j,,  T /V .  Note  that  applying  an  extension  substitution  to  a  computational  kind,  type 
or  expression  applies  it  structurally  to  all  the  dHOL  extension  terms  and  kinds  it  contains.  The  elim¬ 
ination  rule  for  tuples  CExP-ET  IolE  makes  its  two  components  available  in  an  expression  e'  yet  not  at 
the  type  level  -  as  the  exact  value  of  T  is  in  the  general  case  not  statically  available  as  our  example  above 
demonstrates.  These  typing  rules  are  standard  for  dependent  tuples  (also  for  existential  packages,  which 
is  just  another  name  for  the  same  construct). 

As  a  notational  convenience,  we  will  use  the  following  syntactic  sugar: 

(T)  =  (T,  ()) 

(K)  =  (V:K)x  unit 

let(V)=eine/  =  let  (  V,  _ }  =  e  in  e' 

( tx,  T2,  •••  ,Tn )  =  (Tv  {T2,  •••,  (r„))) 

Dependent  dHOL  functions.  Dependent  functions  are  a  necessary  complement  to  dependent  tuples. 
They  allow  us  to  write  functions  where  the  type  of  the  results  depends  on  the  values  of  the  input.  VeriML 
supports  dependent  functions  over  dHOL  extension  terms.  We  denote  their  type  as  (V  :  K)  —*■  r  and 
introduce  them  through  the  notation  XV  :  K.e.  For  example,  the  type  of  an  automated  prover  that 
searches  for  a  proof  object  for  a  given  proposition  is: 

auto  :  (<f) :  ctx )  —*■  ( P  :  \<f>]Prop)  —*■  option  ([<^>]  P ) 

We  have  used  the  normal  ML  option  type  as  the  prover  might  fail;  the  standard  definition  is: 

data  option  a  =  None  |  Some  of  a 

Another  example  is  the  computational  function  that  lifts  the  modus-ponens  logical  rule  to  the  computa¬ 
tional  level: 

mp  :  (<f> :  ctx )  — *■  (P  :  [<^>]  Prop )  —*  (Q  :  [<^>]  Prop)  — > 

mp  =  Xp./.PJ.Q./J/,  :  [9]  P  —  :  [>/,]  P.  ( //,  II, } 

The  typing  rules  for  dependent  functions  CExp-EIHolI  and  CExp-IIHolE  are  entirely  standard  as  is  the 
small-step  semantics  rule  Op-IIHolBeta.  Note  that  the  substitution  T /V  used  in  this  rule  is  the  one- 
element  extension  substitution,  applied  structurally  to  the  body  of  the  function  e. 

Dependent  dHOL  pattern  matching.  The  most  important  dHOL-related  construct  in  VeriML  is  a 
pattern  matching  construct  for  looking  into  the  structure  of  dHOL  extension  terms.  We  can  use  this  con¬ 
struct  to  implement  functions  such  as  the  auto  automated  prover  suggested  above,  as  well  as  the  tautology 
prover  presented  in  Section  2.3.  An  example  is  as  follows:  (note  that  this  is  a  formal  version  of  the  same 
example  as  in  Section  2.3) 
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tautology  :  (<f> :  ctx )  — »  (P  :  [<fi]Prop)  —*■  option  {[(f>]Prop) 

tautology  <]>  P  = 
holmatch  P  with 

(Q  :  [(f)]  Prop,  R  :  [<f>]Prop).[<f>]QAR  > 

do  X  <—  tautology  <f>  {\_<f>]  Q) ; 

Y  <-  tautology  <f>  ([^>]P) ; 
return  (  [^>]<rwc//X  F } 

I  (Q  :  -K  :  \(f>]  Prop).[<j>]  Q—>R  >-*■ 

do  X  <—  tautology  (<f>,  Q)([<f>,  Q]R ) 
return  (  \_cf>\  A (Q).X  } 

|  (P  :  [<f>]  Prop).  [<f>]  P  >-*■  findHyp  cj>  ([<^>]  P) 

The  variables  in  the  parentheses  represent  the  unification  variables  context  whereas  the  following 
extension  term  is  the  pattern.  Though  we  do  not  give  the  details  of  findHyp,  this  is  mostly  similar  as 
in  Section  2.3;  it  works  by  using  the  same  pattern  matching  construct  over  contexts.  It  is  worth  noting 
that  pattern  matching  is  dependently  typed  too,  as  the  result  type  of  the  overall  construct  depends  on  the 
value  of  the  scrutinee.  In  this  example,  the  return  type  is  a  proof  object  of  type  P  -  the  scrutinee  itself. 
Therefore  each  branch  needs  to  return  a  proof  object  that  matches  the  pattern  itself. 

In  the  formal  definition  of  VeriML  we  give  a  very  simple  pattern  matching  construct  that  just  matches 
a  term  against  one  pattern;  more  complicated  pattern  matching  constructs  that  match  several  patterns  at 
once  are  derived  forms  of  this  basic  construct.  We  write  this  construct  as: 

holmatch  T  return  V  :K. r  with  ^!u.Tp^e 

The  term  T  represents  the  scrutinee,  T(<  the  unification  context,  TP  the  pattern  and  e  the  body  of  the 
match.  The  return  clause  specifies  what  the  return  type  of  the  construct  will  be,  using  V  to  refer  to  T. 
We  omit  this  clause  when  it  is  directly  inferrable  from  context.  As  the  typing  rule  CExp-HolMatCH 
demonstrates,  the  return  type  is  an  option  type  wrapping  t[T /V]  in  order  to  capture  the  possibility  of 
pattern  match  failure.  The  operational  semantics  of  the  construct  Op-HolMatch  and  Op-HolNoMatch 
use  the  pattern  matching  algorithm  Tp  ~  T  defined  in  Section  5.1;  the  latter  rule  is  used  when  no  matching 
substitution  exists. 

Type-level  dHOL  functions.  The  last  dHOL-related  construct  available  in  VeriML  is  functions  over 
dHOL  terms  at  the  type  level,  giving  us  type  constructors  over  dHOL  terms.  This  allows  us  to  specify 
type  constructors  such  as  the  following: 

type  eqlist  =  Acf) :  ctx. XT  :  \_<j)\  Type.Wst  ((t1  :  [<^>]  T)  x  (t2  :  \cf>\  T)  X  ([<^>]  t1  =  t2)) 

This  type  constructor  expects  a  context  and  a  type  and  represents  lists  of  equality  proofs  for  terms  of 
that  specific  context  and  type.  Furthermore,  in  order  to  support  recursive  types  that  are  indexed  by 
dHOL  we  adjust  the  typing  rules  for  recursive  type  introduction  and  elimination  CExp-RecI  and  CEXP- 
RecE.  This  allows  us  to  define  generalized  algebraic  data  types  (GADTs)  in  VeriML  as  supported  in  various 
languages  (e.g.  Dependent  ML  [Xi  and  Pfenning,  1999]  and  Haskell  [Peyton  Jones  et  ah,  2006]),  through 
the  standard  encoding  based  on  explicit  equality  predicates  [Xi  et  ah,  2003],  An  example  is  the  vector  data 
type  which  is  indexed  by  a  dHOL  natural  number  representing  its  length: 
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data  vector  an  —  Vnil ::  vector  a  0 

i  Vcons  ::  a  — *■  vector  an'  —*■  vector  a  ( succ  n) 

The  formal  counterpart  of  this  definition  is: 

vector  :  *  — ►  Yin  :  []  Nat.* 

=  Xa  :  ★.^vector :  (Jin  :  []  Nat.*). An  :  []  Nat. 

([] n  =  °)+ 

(( n ' :  []  Nat)  x  a  x  (vector  []  n')  x  ([]  n  —  succ  n')) 

Notational  conventions.  Before  we  conclude  our  presentation  of  the  base  VeriML  computational  lan¬ 
guage,  let  us  present  some  notational  conventions  used  in  the  rest  of  this  dissertation.  We  use  (V1  : 
Ki,  V2:K2,  Vn:Kn)  — >  t  to  denote  successive  dependent  function  types  ( V,  :  K)  — >  (V2  :  K2)  — * 
•  •  •  ( V„  :  Kn)  —*■  t.  Similarly  we  use  (V{  :  K{,  V2:K2,  ,  Vn  :  Kn)  for  the  iterated  dependent  tuple  type 

( Vj  :  Kf)  X  (V2  :  K2)  X  ■■■  (Vn  :  Kn)  X  unit.  We  elide  the  context  $  in  contextual  terms  [<f>]  t  when  it  is 
easy  to  infer;  similarly  we  omit  the  substitution  a  in  the  form  X /a  for  using  the  metavariable  X.  Thus 
we  write  (<f>  :  ctx,  T  :  Type,  t  :  T)  — *  r  instead  of  (<f>  :  ctx,  T  :  [<^>]  Type,  t  :  [<^>]  T / id f)  — >  r.  Last,  we 
sometimes  omit  abstraction  over  contexts  or  types  and  arguments  to  functions  that  are  determined  by 
further  arguments.  Thus  the  above  type  could  be  written  as  (t  :  T)  — *■  t  instead;  a  function  of  this  type 
can  be  called  with  a  single  argument  which  determines  both  cf>  and  T  :  [^]  Type. 

6.1.2  Metatheory 

We  will  now  present  the  main  metatheoretic  proofs  about  VeriML,  culminating  in  a  type-safety  theorem. 
The  usual  informal  description  of  type-safety  is  that  well-typed  programs  do  not  go  wrong.  A  special  case 
of  this  theorem  is  particularly  revealing  about  what  this  theorem  entails  for  VeriML:  the  case  of  programs 
e  typed  as  (P),  where  P  is  a  proposition.  As  discussed  in  the  previous  section,  values  v  =  (  n  )  having  a 
type  of  this  form  include  a  proof  object  n  proving  P.  Expressions  of  such  a  type  are  arbitrary  programs 
that  may  use  all  VeriML  features  (functions,  aHOL  pattern  matching,  general  recursion,  mutable  refer¬ 
ences  etc.)  in  order  to  produce  a  proof  object;  we  refer  to  these  expressions  as  proof  expressions.  Type 
safety  guarantees  that  if  evaluation  of  a  proof  expression  of  type  (P)  terminates,  then  it  will  result  in  a  value 
(  n  )  where  n  is  a  valid  proof  object  for  the  proposition  P.  Thus  we  do  not  need  to  check  the  proof  object 
produced  by  a  proof  expression  again  using  a  proof  checker.  Another  way  to  view  the  same  result  is  that 
we  cannot  evade  the  xHOL  proof  checker  embedded  in  the  VeriML  type  system  -  we  cannot  cast  a  value 
of  a  different  type  into  a  proof  object  type  (P)  only  to  discover  at  runtime  that  this  value  does  not  include 
a  proper  proof  object.  Of  course  the  type  safety  theorem  is  much  more  general  than  just  the  case  of  proof 
expressions,  establishing  that  an  expression  of  any  type  that  terminates  evalutes  to  a  value  of  the  same 
type.  A  sketch  of  the  formal  statement  of  this  theorem  is  as  follows: 

b  e  :  t  e  terminates 

- - Type  safety 

e  — >*  v  b  v  :  r 

As  is  standard,  we  split  this  proof  into  two  main  lemmas:  preservation  and  progress. 

b  e  :  r  e  — ►  e  b  e  :  r  efv 

- Preservation  - Progress 

i_  /  n  /  /  ° 

re:  r  de  .e  — ►  e 
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Compatibility  of  store  with  store  typing: 

Vl,v.{l  >->  v)  E  jj.  =>  3r.(/  :  r)  E  M.  A  •;  M.;  •  b  v  :  r 
V/,t.(/  3f.(/  <->■  v)E  p  A  •;  A4;  •  b  z; :  t 

p  ~  M. 


Store  typing  subsumption: 
V/,  t.(/  :  r )  E  M.  =>  {l  t)  E  M! 
MCM' 


/^-equivalence  for  types  r 
(used  in  CExp-Conv)  is  the 

compatible  closure  of  the  relation:  Canonical  and  neutral  types: 


(dor : /C.t)  r7  t[t' / a] 

( \V:K.t)T  =p  r  [T/V] 

( Canonical  types )  tc  ::=  unit  |  rj  — *■  rc2  |  tJ  x  t/  | 

|  da:/Crc  |  r”  |  (V:K)~ 

(Neutral  types)  r”  ::=  a  |  pa  :  &.tc  |  r”  t/  |  r” 


Tj  +  Tj  |  ref  rc  |  Va  :  k.rc 
►  tc  |  ( V:K)xtc  |  dV:iCrc 
T 


Figure  6.10:  VeriML  computational  language:  definitions  used  in  metatheory 

In  a  way,  we  have  presented  the  bulk  of  the  proof  already:  establishing  the  metatheoretic  proofs  for  dHOL 
and  its  extensions  in  Chapters  4  and  5  is  the  main  effort  required.  We  directly  use  these  proofs  in  order  to 
prove  type-safety  for  the  new  constructs  of  VeriML;  and  type-safety  for  the  constructs  of  the  ML  core  is 
entirely  standard  [e.g.  Pierce,  2002,  Harper,  2011], 

We  give  some  needed  definitions  in  Figure  6.10  and  proceed  to  prove  a  number  of  auxiliary  lemmas. 

Lemma  6.1.1  (Distributivity  of  computational  substitutions  with  extension  substitution  application) 

L  (t[V/ =  t  ■  g^[t'  ■  / a] 

2.  (e[r/a])-o-^  =  e  ■  ■  a^/a] 

3.  (e[ef x])-a^  =  e  ■  a9[ef-a9/x] 

Proof.  By  induction  on  the  structure  of  r  or  e.  □ 

Lemma  6.1.2  (Normalization  for  types)  For  every  type  r,  there  exists  a  canonical  type  rc  such  that  r  —p  rc. 

Proof.  The  type  and  kind  level  of  the  computational  language  can  be  viewed  as  a  simply-typed  lambda 
calculus,  with  all  type  formers  other  than  Xa  :  k.r  and  XV  :  K.r  being  viewed  as  constant  applications. 
Reductions  of  the  form  ( XV  :  K.r)  T  — » «  r[T / V ]  do  not  generate  any  new  redeces  of  either  form; 
therefore  normalization  for  STLC  directly  gives  us  the  desired.  □ 

Based  on  this  lemma,  we  can  view  types  modulo  /^-equivalence  and  only  reason  about  their  canonical 
forms. 

Lemma  6.1.3  (Extension  substitution  application  for  computational  language) 

T  b  L  wf  'P/  b  :  T  T  b  kwf  VP/  b  a\j, :  T  f;  TbiT  'P/  b  :  T 

1. -  2. -  3. - 

'P/  b  T  •  aq,  wf  T/  b  k  ■  dq,  wf  'lb;  T  •  b  r  ■  :  k  ■ 
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'I1;  A4;  Their  'P/  h  $ 

4. - 

M;  T  •  a9  b  e  ■  ay  :  r  ■  ay 

Proof.  By  structural  induction  on  the  typing  derivation  for  k,  r  or  e.  We  prove  two  representative  cases. 

Case  CTyp-LamHol. 

%  V:K;T\-r:k 
'P;  Th(dV  :K.r):(UV  :K.k) 

By  induction  hypothesis  for  r  with  the  substitution  a]  =  ay,  V/V  typed  as 
*',V:K-ay  b  (ay,  V/V )  :(V,V:  K ),  we  get: 

V',  V  :K  ■  ay,  T  •  a'^  h  r  •  :  k  ■  a'^ 

Note  that  V/V  is  stands  either  for  ([<P  •  ay\X /idy,af)/X  when  V  =  X  and  K  =  [<P]  t';  or  for  ([<P  • 
<rlI;]  S)/ S  when  V  =  S  and  K  =  [<P]  ctx,  as  is  understood  from  the  inclusion  of  extension  variables  into 
extension  terms  defined  in  Figure  5.3. 

From  the  fact  that  'P  h  T  wf  we  get  that  T-  a'^  =  T-  ay.  We  also  have  that  r  •  a'^  =  t  •  ay  and  k-a'^  =  k-  ay. 
(Note  that  such  steps  are  made  more  precise  in  our  Technical  report  [Stampoulis  and  Shao,  2012b]  through  the 
use  of  hybrid  deBruijn  variables  for  'P ) 

Thus: 

T',  V  :K  ■  ay;T  ■  ay\~  r  ■  ay  :  k  ■  ay 

Using  the  same  typing  rule  CTyp-LamHol  we  get: 

T';  r-u^h  (XV  :  K  ■  ay. r  ■  ay) :  (flV  :  K  ■  ay.k  ■  ay),  which  is  the  desired. 


Case  CExp-E[HolE. 

M;  T\~e:(V  :K)^t  T  b  T:K\ 

\  V-,M-,r\-eT:T-(idy,T/V)  ) 

By  induction  hypothesis  for  e  we  have: 

T';  M ;  T  •  ay  b  e  ■  ay  :  ( V  :  K  •  ay)  -»  r  •  ay 

Using  the  extension  substitution  theorem  of  bHOL  (Theorem  4.2.6)  for  T  we  get: 

^'\-T  -ay\  K- ay 

Using  the  same  typing  rule  we  get: 

'P';  M;  T  ■  ay  b  (e  ■  ay)  ( T  ■  ay)  :(r  -ay  (idy,  T  ■  ay/V)) 

Through  properties  of  extension  substitution  application  we  have  that: 
ay  •  (idy',  T  ■  ay/V)  =  (idy,  T /V)  ■  ay  thus  this  is  the  desired. 


Case  CExp-HolMatch. 


f*Pb  T-.K 


T,  V  :  if;  T  b  r  :  ★  ^\/^H>TP:K 


\ 

T,  H>u-,M-,r\-e':T-(idy,  TP/V) 


\P;  M;  T  b 


holmatch  T  return  V  :K.r 
with  T^.Tp  >->■  e 


:  r  •  (idy,  T /V)  +  unit 


/ 


We  have: 

'P/  b  T  ■  ay  :K  ■  ay,  through  Theorem  4.2.6  for  T 
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V,  V  :  K  ■  aq,;  T  •  aq,  b  t  •  aq, :  *,  using  part  3  for  r  with  a ^  =  a q/,  V /V 

u  ■  <jq,  >  Tp  ■  <jq  :  K  ■  <7^,  directly  using  the  extension  substitution  application  theorem  for  patterns 
(Theorem  5.1.7) 

Th  u  ■  aq,  b  e'  ■  (aq,,  idq,  )  :  r  •  (m?^,  Tp/V)  ■  (aq,,  idq,  ),  through  induction  hypothesis  for  e'  with 
aq,  =  (o^,  typed  as  T';  h  (o^,  z'c/^)  :  (T,  T(<) 

•“  e’  ■  aq,  :  r  ■  (idq,/,  TP  ■  (7q,/V),  through  properties  of  extension  substitutions 
Thus  using  the  same  typing  rule  we  get: 

holmatch  T  ■  aq, 

ty';  Ai;  T  •  aq,  b  return  V  :  K  ■  <jq,.r  ■  aq,  :  (r  •  aq,)  ■  (idq,/,  (T  ■  aqf/V)  +  unit 

with  •  (Jq,.Tp  ■  aq,  e'  ■  aq, 

This  is  the  desired  since  (r  •  aq,)  ■  (idq,/,  (T  ■  aq,)/V )  =  (r  ■  (idq,,  T /V))  ■  aq,.  □ 

Lemma  6.1.4  (Computational  substitution) 

T,  T/  hr,  a  :  k',  T;  wf  T;  T  h  x  :  k'  T,  'P/;  T,  a  :  k' ,  h  x  :  k  f;  Thr  :  k' 

1. -  2. - 

T,  T/  h  T,  Y\t' /a)  wf  T,  \fd;  T,  Y\x' /a)  h  x\x'  )a\  :  k 

T,  \fd;  Ai;  Y ,  a  :k' ,Y:  \~  e  :  x  T;  T  h  x  :  k' 

3. - 

T,  X';  At;  T,  Y\f  /a]  h  e[x 1  /a  \  :  x[x  fa) 

T,  ltd;  Ai;  T,  x  :  t  ,Y:  \~  e  :  t  T;  Ai;  T  h  e  :  x' 

4. - 

T,  V;  Ai;  T,  T/  h  e[e' /x']  :  x 

Proof.  By  structural  induction  on  the  typing  derivations  for  T,  x  or  e.  □ 

Theorem  6.1.5  (Preservation) 

•;A4;»be:r  (pi,e) — >•  (  pi'  ,  e  )  pi  ~  Ai 
3Ai' .(  •;  Ai' ;  »\~  e' \  x  AiCAi'  pi' ~  Ai'  ) 

Proof.  By  induction  on  the  derivation  of  (pi ,  e)  — ►  (  u  ,  e' ).  In  the  following,  when  we  don’t  specify 
a  different  pi' ,  we  have  that  pi'  =  pi.  We  present  the  /HOL-related  constructs  first;  the  cases  for  the  ML 
core  follow. 

Case  Op-IIHol-Beta. 

[(pi,(AV:K.e)T)  — >  ( pi ,  e -(T /V))\ 

By  typing  inversion  we  have: 

•;Ai;»\~  (XV  :K.e):(V  :K)^x',  •  h  T:K,  x  =  x'-(T/V) 

By  further  typing  inversion  for  XV  :  K.e  we  get: 

V:K;  Ai;  •he:r' 

For  aq,  =  (•,  T /V)  (also  written  as  aq,  =  (T /V))  we  have  directly  from  typing  for  T:  •  b  (T /V):(V  :K) 
Using  Lemma  6.1.3  for  aq,  we  get  that: 

•;  At;  •  he-(T/V):x'-(T/V) 
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Case  Op-EHol-Unpack. 

[(/u,  let  (  V,  x)  =  (T,  v){v.K)xr»  ine')  — ♦  ( /u  ,  (e  ■  (T/V))[v/x\ )] 

By  inversion  of  typing  we  get: 

•;  A4;  •  I-  (  T,  v  }(y.^)XT"  :  ( V  :  K )  x  r';  V  :K;  M;  x  :  r  h  e' :  t;  •;  •  hr:* 

By  further  typing  inversion  for  (  T,  V  :K)  r"  v  we  get: 
r  " —  x'\  *1 ~T:K;  V  :  K;  •  h  r' :  *;  •;  A4;  •  h  v  :  r'  ■  (T/V) 

First  by  Lemma  6.1.3  for  e'  with  =  T/V  we  get: 

•;  M;  x:T,-(T/V)he'-(T/V):T-(T/V) 

We  trivially  have  that  r  ■  (T /V)  =  r,  thus  this  equivalent  to: 

•;  M;  x:T,-(T/V)he/-(T/V):r 

Last  by  Lemma  6.1.4  for  \y  /x\  we  get  the  desired: 

•;  M;  •  h  (e'  ■  ( T /V))[v/x]  :  r 

Case  Op-HolMatch. 

TP  ~  T  = 

(  jj  ,  holmatch  T  with  ^  irTP  >-*■  e  )  — *■  (  [j  ,  injj  (e/  •  ) 

By  typing  inversion  we  get: 

•  I -T:K,  V:K;»  hr':*,  •  £  >  7>  :  h  e' :  r'  -(Tp/V),  t  =  r'  ■  (T/V)  +  unit 

Directly  by  soundness  of  pattern  matching  (Lemma  5.1.13)  we  get: 

•1 Tp-a^  =  T 

Through  Lemma  6.1.3  for  e'  and  we  have: 

•  h  e'  ■  ay  :  t'  •  ( TP/V )  ■  a,v 

We  can  now  use  the  typing  rule  CExp-SumI  to  get  the  desired,  since: 

(TP/V)  ■  <j^  =  (TP  ■  a^/V)  =  (T/V) 

Case  Op-HolNoMatch. 

TP  ~  T  =  fail 

(  jj  ,  holmatch  T  with  T U.TP  *-*■  e )  — *  (  /j  ,  inj2  () ) 

Trivial  using  the  typing  rules  CExp-SumI  and  CExp-Unit.  Note:  Though  completeness  for  pattern 
matching  is  not  used  for  type-safety,  it  guarantees  that  the  rule  Op-HolNoMatch  will  not  be  used  unless 
no  matching  substitution  exists. 

Case  Op-Env. 

(fu,e) — *•(//,  e) 

_([j.,£[e]) — ♦( //,£[<?'])_ 

By  induction  hypothesis  for  ( y. ,  e )  — >  ( y! ,  e' )  we  get  a  Ai'  such  that  M.  C  A47,  yl  ~  M.'  and 
•;  Ai;  •  b  e'  :  r.  By  inversion  of  typing  for  £[e]  and  re-application  of  the  same  typing  rule  for  £|V] 
we  get  that  •;  Ai';  •  h  £ |V]  :  r. 
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Case  Op-Beta. 

[( [d  ,{Ax:  r.e)  v)  — »  ( jd  ,  e[v/x]  )] 

By  inversion  of  typing  we  get:  •;  A4;  •  b  Ax  :  r.e  :  x'  — *  r,  •;  A4;  •  h  v  :  x' 

By  further  typing  inversion  for  Ax  :  r.e  we  get:  •;  A4;  x  :  x  b  e  :  x 
By  lemma  6.1.4  for  \v /x]  we  get:  •;  A4;  •  h  e\v /x~\  :  x 

Case  Op-Proj. 

[(/“>  ProhK>  ^2))  — *((*,  *;)] 

By  typing  inversion  we  get:  •;  A4;  •  h  (vv  v2) :  xl  X  r2,  t  =  r- 
By  further  inversion  for  (vly  v2)  we  have:  •;  A4;  •  h  v-  :  Xj 

Case  Op-Case. 

[(/•<>  case(inj-  v,  x.ev  x.e2) )  — *  (  jj  ,  e-|>/x])] 

By  typing  inversion  we  get:  •;  A4;  •  h  v  :  t-;  •;  A4;  x  :  t  -  h  e-  :  t 
Using  the  lemma  6.1.4  for  [v/x]  we  get:  •;  A4;  •  h  e •  [?;/%]  :  t 

Case  Op-Unfold. 

[(  /2  ,  unfold  (fold  v) )  — *■  (  y. ,  v  )] 

By  typing  inversion  we  get:  •;  •  h  fua  :  k.r  :  k%,  •;  A4;  •  h  fold  v  :  (/2a  :  &.U)  al  a2  an ;  every 

a-  =  r  -  or  T-;  x  =  :  k.r]  a1a2  •••  an 

By  further  typing  inversion  for  fold  v  we  have  •;  A4;  •  h  v  :  T/[(uar :  k.r  /  cc\  axa2  •  •  ■  an 

Case  Op-NewRef. 

“■(/  fd) 

_([d,refv) — /)_ 

By  typing  inversion  we  get:  •;  A4;  •  h  v  :  x' 

For  AT  =  A4,  /  :  r  and  /u'  =  /u,  l  >->  v  we  have  that  //  ~  AT  and  •;  AT;  •  h  /  :  ref  x' . 

Case  Op-Assign. 

I  1 — >  _  G  /2 

_(  a*  » / :=,z;) — -*•*']  -  0). 

By  typing  inversion  get:  •;  A4;  •  h  /  :  ref  T;  •;  A4;  •  h  -y  :  T 

Thus  for  /u'  =  /u[l  <->  v~\  we  have  that  y!  ~  AT  Obviously  •;  A4;»  h  () :  unit. 

Case  Op-Deref. 
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/  v  €.  jj 


L(  a*  > !/) — >(/u’  v)\ 

By  typing  inversion  get:  •;  Ad;  •  h  /  :  ref  x 
By  inversion  of  jj  ~  Ad  get: 

•;  A4;  •  h  v  :  r,  which  is  the  desired. 


Case  Op-PolyInst. 

[(/•C  (A a:k.e)  x"  )  — e[r "/«])] 

By  typing  inversion  we  get:  •;  Ad;  •  h  A  a  :  k.e  :  Ha  :  k.x';  •;  •  h  x"  :  k\  x  = 
By  further  typing  inversion  for  A  a  :  k.e  we  get:  •;  Ad;  a  :  k  h  e  :  x' 

Using  Lemma  6.1.4  for  e  and  [r^/ar]  we  get:  •;  Ad;  •  h  efr^/a]  :  x '\x" / a\ 

Case  Op-Fix. 

[(  ju  ,  fix  x  :  x.e  )  — *  ( [J  ,  e[fix  %  :  x.e/x\  )J 

By  typing  inversion  get:  •;  Ad;  %  :  x  h  e  :  x 

By  application  of  Lemma  6.1.4  for  e  and  [fix  %  :  x.e/x]  we  get: 

•;  Ad;  •  h  e[fix  %  :  x.e/x ]  :  x 


Lemma  6.1.6  (Canonical forms)  If  •;  Ad;  •  h  v  :  x  then: 


Ifr  =  -- 

(V:K)-^x' 

(V-.K)xx' 

unit 

x{->x2 

X\  X 

XY  +  X2 

(/ ia  :  k.x')  ax  a2 
refx' 

Va :  k.x' 


then  exists  ■  ■  ■ 


e 

T,v' 


e 

Vi,v2 

v' 

an  V 

l 

e 


such  that  v  —  ■■■ 

A  V:K.e 

(  T’  V')(V:K)xt"  ™Mx'=p  x" 
0 

Ax  :  Tj.e 
v2 ) 

injl  v'  or  inj2  v' 
fold  v' 

l 

A  a  :  k.e 


Proof.  Directly  by  typing  inversion  on  the  derivation  for  v. 
Theorem  6.1.7  (Progress) 


□ 


□ 


•;Ad;*he:r  jj  ~  Ad  efv 
3/u',e'.(/u  ,  e) — *•(//,  e' ) 

Proof.  By  induction  on  the  typing  derivation  for  e.  We  do  not  consider  cases  where  e  =  £\e"],  without 
loss  of  generality:  by  typing  inversion  we  can  get  that  e"  is  well-typed  under  the  empty  context,  so  by 
induction  hypothesis  we  get  /j",  e’"  such  that  (  jj.  ,  e"  )  — *■  (  y."  ,  e"’  ) .  Thus  set  y.’  —  y."  and  e’  —  £  [e'"] ; 
by  Op-Env  get  (  [i ,  <£T  [e7/]  )  — ►  ( [i ,  £i[e///]  ).  Most  cases  follow  from  use  of  canonical  forms  lemma 
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(Lemma  6.1.6),  typing  inversion  and  application  of  the  appropriate  operational  semantics  rule.  We  give 
the  /HOL-related  cases  as  a  sample. 


Case  CExp-IIHolE. 

/ •;  M;  •  h  v  :  ( V  :  K)  — *  x  •  h  T  :K\ 

\  •;  A4;  •  h  v  T  :  r  ■  (T/V)  ) 

By  use  of  canonical  forms  lemma  we  get  that  v  =  XV  :  K.e.  Through  typing  inversion  for  v  we  get 

V  :  K ;  A4 ;  •  h  e  :  t'.  Thus  e  ■  ( T /V)  is  well-defined  (it  does  not  depend  on  variables  other  than  V).  Using 
Op-IIHol-Beta  we  get  e'  =  e  ■  (T /  V)  with  the  desired  properties  for  y.’  =  fj. 

Case  CExp-EHolE. 

(  •;  A4;  •  h  v  :  (V  :  K )  x  t  V  :  K ;  A4;  x  :  t  b  e"  :  t  ^ 

•  h  t  :  * 

•;  Ad;  •  b  let  (  V,  x  )  =  v  in  e"  :  r 

V  ) 

Through  canonical  forms  lemma  we  get  that  v  =  (  T,  v’  )ty.K^Xr'-  From  typing  of  e'  we  have  that  e"  ■ 
( T / V )  is  well-defined.  Therefore  using  Op-EHol-Unpack  we  get  e'  =  (e"-(T /U))[^/x]  with  the  desired 
properties. 


Case  CExp-HolMatch. 


(•b  T:K 


V 


V  :K;  •hr/: 


:  ★ 


•I 


.  ,  .  holmatch  T  return  V  :K.r 

with  •u  .1  p  e 


\ 

•«;  •he//:T/-(rp/y) 


:  r  -(T /V)  +  unit 


We  split  cases  on  whether  Tp  ~  T  =  or  Tp  ~  T  =  fail.  In  the  first  case  rule  Op-HolMatch  applies, 
taking  into  account  the  fact  that  e"  ■  o\[;  is  well-defined  based  on  typing  for  e" .  In  the  second  case  Op- 
NoHolMatCH  directly  applies.  □ 


Theorem  6.1.8  (Type  safety  for  VeriML) 


*;Ad;»he:r  y  ~  M.  efv 


~^y,  M' ,e  (y,e) — >  (  y  ,  e  )  •;AI/;*he/:T  y  ~  M!  ) 

Proof.  Directly  by  combining  Theorem  6.1.5  and  Theorem  6. 1.7. 


□ 


6.2  Derived  pattern  matching  forms 

The  pattern  matching  construct  available  in  the  above  definition  of  VeriML  is  the  simplest  possible:  it 
allows  matching  a  scrutinee  against  a  single  pattern.  In  this  section,  we  will  cover  a  set  of  increasingly 
more  complicated  pattern  matching  forms  and  show  how  they  are  derived  forms  of  the  simple  case.  For 
example,  we  will  add  support  for  multiple  branches  and  for  multiple  simultaneous  scrutinees.  We  will 
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present  each  extension  as  typed  syntactic  sugar,  every  new  construct  will  have  its  own  typing  rules  and 
operational  semantics,  yet  we  will  give  a  syntax-  or  type-directed  translation  into  the  original  VeriML 
constructs.  Furthermore,  we  will  show  that  the  translation  respects  the  semantics  of  the  new  construct. 
In  this  way,  the  derived  forms  are  indistinguishable  to  programmers  from  the  existing  forms,  as  they  can 
be  understood  through  their  typing  rules  and  semantics;  yet  our  metatheoretic  proofs  such  as  type  safety 
do  not  need  to  be  adapted. 

The  first  extension  is  multiple  branches  support  presented  in  Figure  6.11.  This  is  a  simple  extension  that 
allows  us  to  match  the  same  scrutinee  against  multiple  patterns,  for  example: 

holMultMatch  P  with  Q  AR  >-*■  ex  |  Q  Vi?  >-*■  e2 

The  pattern  matches  are  attempted  sequentially,  with  no  backtracking;  the  branch  with  the  first  pattern 
that  matches  successfully  is  followed  and  the  rest  of  the  branches  are  forgotten.  The  pattern  list  is  not 
checked  for  coverage  or  for  non-redundancy.  The  construct  returns  a  type  of  the  form  t  +  unit;  the  unit 
value  is  returned  in  the  case  where  no  pattern  successfully  matches,  similarly  to  the  base  pattern  matching 
construct. 

We  show  that  our  definitions  of  the  typing  rule  and  semantics  for  this  construct  are  sensible  by  proving 
that  they  correspond  to  the  typing  and  semantics  of  its  translated  form. 


Lemma  6.2.1  (Pattern  matching  with  multiple  branches  is  well-defined) 


T;  R4;  T  h  (  holMultMatch  T  with'Xl u.Tp 


1. 


T;  M;  T  h 


holMultMatch  T  with'S/ll.Tp 


holMultMatch  T  with  T^.Tp  *-*■  e  — >  e 
holMultMatch  T  with  ^U-Tp  >-*■  e  J  — +*  e 

Proof.  Part  1  follows  directly  from  typing;  similarly  part  2  is  a  direct  consequence  of  the  operational 
semantics  for  the  translated  form.  □ 

The  second  extension  we  will  consider  is  more  subtle;  we  will  introduce  it  through  an  example.  Con¬ 
sider  the  case  of  a  tactic  that  accepts  a  proposition  and  its  proof  as  arguments;  it  then  returns  an  equivalent 
proposition  as  well  as  a  proof  of  it. 

tactic  :  (P  :  Prop,  H:P)^(P':  Prop,  H' :  P') 

=  XP  :  Prop.XH  :  P.holMultMatch  P  with 
Q  AP  >-»■  ( P  A  Q,  •••} 

QVP->(PVQ,  •••} 

In  each  branch  of  the  pattern  match,  we  know  that  P  is  of  the  form  Q  A  R  or  Q  V  R;  yet  the  input  proof 
is  still  typed  as  H  :P  instead  of  H  :  Q  AR  or  H  :  QV  R  respectively.  The  reason  is  that  pattern  matching 
only  refines  its  return  type  but  not  the  environment  as  well.  We  cannot  thus  directly  deconstruct  the 
proof  H  in  order  to  fill  in  the  missing  output  proofs.  Yet  an  easy  workaround  exists  by  abstracting  again 
over  the  input  proof,  owing  to  the  fact  that  the  matching  construct  does  refine  the  return  type  based  on 
the  pattern: 
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Syntax 


e  ::=  •  •  •  |  holMultMatch  T  return  V  :  K.r  with  'I ! U.TP  e' 


Typing 


TbT:  K  T,  V 

Vr.(  T  h;  >  7^  T,  T^;  M;  T  b  e\ :  r  •  («f*,  7^/V) 


T;  A4;  Th 


^  holMultMatch  T  ^ 
return  V  :K.t 


:  r  •  (r4>  T /V)  +  unit 


\  with  mu.Tp^e'  j 


Semantics 


4,1  ~  T  —  (j^, 

holMultMatch  T  with  (T^.Tp!  ej  |  •••  |  -4, «  -*•  «») — *■  inji  (<h  •  <r9) 

4,i  ~  T  =  error 

holMultMatch  T  with  (T  ,.Tn  ,  —>■  e,  I  •  •  •  IT  „.TP  >- *■  e  )  — *■ 
holMultMatch  T  with  (T^.Tp^  -*■  e2  I  •  •  •  I  ^ *,„-4,«  -*•  eJ 


holMultMatch  T  with  ()  — »■  inj2  () 


Translation 

holMultMatch  T  with  Ta.TP  >->■  e  J  = 
case(holmatch  T  with  Ta  vTPl  >-*■  e1,  x.inj,  x, 
y.case(holmatch  T  with  T„  2-4,2  e2>  ^-inji  x, 

y- ■  ■  ■  (case(holmatch  T  with  Tu  n.TPn  ->•  en,  x.inj x  x,  y.inj2  y)))) 


Figure  6.11:  Derived  VeriML  pattern  matching  constructs:  Multiple  branches 
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Syntax 


e  ::=  •••  |  holEnvMatch  Vs  return  r  with  ^U-Tp  '-*■  e' 


Typing 


*  =  *0,  VS:K,^  WThr:*  ^>^U>TP:K 
a-q,  =  idx j,q,  TP/VS,  idq T  =  T0,  Vs  :  Tj  •  aq, 
'F/,  M-,T  -Gq,\-  e'  :t  -aq. 


T;  M;  T  h 


holEnvMatch  Vs  \ 
return  r 

with  tyu.Tp  <->  e  ) 


t  •  Gq,  +  unit 


Semantics 


(e  ■  dq,  =  e'  when  Gq,.V$  =  T) 


If  T  =  V' :  (holEnvMatch  Vs  return  r  with  TK.Tp  e')  ■  Gq,  = 

holEnvMatch  V'  return  r  •  cr^  with  T(<  •  Gq,.TP  ■  Gq,  e:  ■  Gq, 

If  T  fi  V' :  (holEnvMatch  Vs  return  r  with  Tw.Tp  >-»■  e')  •  = 

holmatch  T  return  Vs.r  •  Gq,  with  H  ■  Gq,.Tp  ■  Gq,*-*  e’  ■  Gq, 


Translation 


_ *  =  *0,  VS:K,  _ 

[[T;  R4;  T  h  holEnvMatch  Vs  return  r  with  T u.Tp  >-*■  e  :  t/]]  = 
(holmatch  Vs  return  Vs  :  K.(\ F)  — >  T  — *■  r  with  T u.Tp  <->  /iT./lr.e)  T  T 


Figure  6.12:  Derived  VeriML  pattern  matching  constructs:  Environment-refining  matching 

tactic  :  (P  :  Prop,  H:P)->(P':  Prop,  H1 :  P') 

=  aP  :  Prop.  AH  :  P. 

(holMultMatch  P 

return  P' :  Prop.(H  :  P')  — ►  ( P 1 :  Prop,  H' :  P')  with 
QAR^AH :  QAR.(RAQ,  •••} 

QW  R  ^  AH  :  QW  R.  (RW  Q,  ■  ■  ■ ))  H 

More  formally,  we  introduce  environment-refining  pattern  matching:  when  the  scrutinee  of  the  pattern 
matching  is  a  variable  V,  all  the  types  in  the  current  context  that  depend  on  V  get  refined  by  the  current 
pattern.  We  introduce  this  construct  in  Figure  6. 12.  We  only  show  the  case  of  matching  a  scrutinee  against 
a  single  pattern;  multiple  patterns  can  be  supported  as  above.  We  are  mostly  interested  in  the  typing  for 
this  construct.  The  construct  itself  does  not  have  operational  semantics,  as  it  requires  that  the  scrutinee 
is  a  variable.  Since  the  operational  semantics  only  handle  closed  computational  terms,  an  occurrence  of 
this  construct  is  impossible.  The  only  semantics  that  we  define  have  to  do  with  extension  substitution 
application:  when  the  scrutinee  variable  Vs  is  substituted  by  a  concrete  term,  the  environment-refining 
construct  is  replaced  with  the  normal,  non-refining  pattern  matching  construct.  Our  definition  of  this 
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construct  follows  the  approach  of  Crary  and  Weirich  [1999],  yet  both  the  typing  and  semantics  are  unsat- 
isfyingly  complex.  A  cleaner  approach  would  be  the  introduction  of  a  distinguished  computational  type 
T  zzT'  reflecting  the  knowledge  that  the  two  extension  terms  unify,  as  well  as  casting  constructs  to  make 
explicit  use  of  such  knowledge  [similar  to  Goguen  et  ah,  2006];  still  this  approach  is  beyond  the  scope  of 
this  section. 

Lemma  6.2.2  (Pattern  matching  with  environment  refining  is  well-defined) 

\b;  Ai;  F  b  ( holEnvMatch  T  with  \b U.TP  *— >■  e/)  :  t 

[[T;  Ai;  r  b  holEnvMatch  T  with  'FU.TP  e  :  t/T]  =  e" 

1. - 

T;  M;  r  b  e"  :  r 

( holEnvMatch  Vs  with  T H.TP  >->  e)  ■  o^,  =  e 
[[\b;  At;  F  b  holEnvMatch  T  with  T U.TP  >— >■  e  :  =  e" 

II  / 

e  -o-^  —  e 

Proof.  Similarly  as  above;  direct  consequence  of  typing  and  extension  substitution  application.  □ 

The  last  derived  pattern  matching  form  that  we  will  consider  is  simultaneous  matching  of  multiple 
scrutinees  against  multiple  patterns.  The  pattern  match  only  succeeds  if  all  scrutinees  can  be  matched 
against  the  corresponding  pattern.  This  is  an  extension  that  is  especially  useful  for  comparing  two  terms 
structurally: 

holSimMatch  P,  Q  with  A  A  B,  A'  AB'  >-*■  e 

We  can  also  use  it  in  combination  with  environment-refining  matching  in  order  to  match  a  term  whose 
type  is  not  yet  specified: 

AT  :  Type. At :  T.holSimMatch  T,  t  with  Nat,  zero  >-*■  e 

We  present  the  details  of  this  construct  in  Figure  6.13.  Typing  and  semantics  are  straightforward;  the 
only  subtle  point  is  that  the  unification  variables  of  one  pattern  become  exact  variables  in  the  following 
pattern,  as  matching  one  scrutinee  against  a  pattern  provides  them  with  concrete  instantiations. 

Lemma  6.2.3  (Simultaneous pattern  matching  is  well-defined) 

\b;  At;  T  b  (holSimMatch  T  with  (fit H.Tp)  >— >  e  \  :  r 

1. - - - — -  , - - - 

'b;Af;Tb  holSimMatch  T  with  (\b;<.7p)  >— *  :  t 

holSimMatch  T  with  (\b U.TP)  <-*  e — ►  e 
holSimMatch  T  with  (fi>lt.TP)  >-*■  e  J  — >*  e' 

Proof.  Similar  to  Lemma  6.2.1.  □ 

In  the  rest  we  will  freely  use  the  holmatch  construct  to  refer  to  combinations  of  the  above  derived  con¬ 
structs. 
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Syntax 


e  ::=•••  |  holSimMatch  T  return  V  :  K.r  with  (xYu.Tp) 


Typing 


%  Vl:Kv...,Vn:Kn;Y\-T:* 

*?p*u,i>Tpy-Ki  *^u,^»,2>Tpy-K2  ••• 

^U,v  •••  >  >1;  r  h  e  :  T •  {idy,  TPl/Vv  ■■■,  TPn/Vn) 


( 


T;  M;  Th 


holSimMatch 


7  \ 


return  V :  K.r 
y  with  XY u.Tp  i-*  e  J 


■  p  ■  {id,v,  TJVU  ••• ,  Tn/V„)  +  unit 


Semantics 

Tp,\  ~T\  =  <J\,  ‘  ‘  ‘  Tp,n  ~Tn=a^ 

holSimMatch  T  with  (^„;1.TP1)  -»•  e — *  in^  (e  •  (o^,  ••• ,  <r”)) 

_ TP,i  ~rt  =  error _ 

holSimMatch  T  with  (T;(  1.TP  j)  e — Mnj2() 

Translation 

holSimMatch  T  with  T(<.7p  >-*■  e  J  = 

holmatch  Tx  with  vTp  2  >->  do  holmatch  Ti,  with  2.Tp,  >->■•••  >->■ 

(holmatch  Tn  with  XY u  n.TP  n  >->  do  e ) 


Figure  6.13:  Derived  VeriML  pattern  matching  constructs:  Simultaneous  matching 
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6.3  Staging 

In  the  simplify  example  presented  in  Section  2.3  and  also  in  Section  5.2,  we  mentioned  that  we  want 
to  evaluate  certain  tactic  calls  at  the  time  of  definition  of  a  new  tactic.  We  use  this  in  order  to  ‘fill  in’ 
proof  objects  in  the  new  tactic  through  existing  automation  code;  furthermore,  the  proof  objects  are 
created  once  and  for  all  when  the  tactic  is  defined  and  not  every  time  the  tactic  is  invoked.  We  will 
see  more  details  of  this  feature  of  VeriML  in  Section  7.2,  but  for  the  time  being  it  will  suffice  to  say 
that  it  is  the  combination  of  two  features:  a  logic-level  feature,  which  is  the  transformation  of  dHOL 
open  terms  with  respect  to  the  extension  context  'I'  to  equivalent  closed  terms,  presented  in  Section  5.2; 
and  a  computational-level  feature,  namely  the  ability  to  evaluate  subexpressions  of  an  expression  during 
a  distinct  evaluation  stage  prior  to  normal  execution.  This  latter  feature  is  supported  by  extending  the 
VeriML  computational  language  with  a  staging  construct  and  is  the  subject  of  this  section. 

We  will  start  with  an  informal  description  of  staging.  Note  that  the  application  we  are  interested  in  is 
not  the  normal  use  case  of  staging  (namely,  the  ability  to  write  programs  that  generate  executable  code). 
Our  description  is  thus  more  geared  to  the  use  case  we  have  in  mind.  Similarly,  the  staging  construct  we 
will  add  is  quite  limited  compared  to  language  extensions  such  as  MetaML  [Taha  and  Sheard,  2000]  but 
will  suffice  for  our  purposes. 

Constant  folding  is  an  extremely  common  compiler  optimization,  where  subexpressions  composed 
only  from  constants  are  replaced  by  their  result  at  compilation  time.  A  simple  example  is  the  following: 

An  :  int .n  *  10  *  10  An  :  int .n  *  100 

The  subexpression  10  *  10  can  trivially  be  replaced  by  100  yielding  an  equivalent  program,  avoiding  the 
need  to  perform  this  multiplication  at  runtime.  A  more  sophisticated  version  of  the  same  optimization  is 
constant  propagation,  which  takes  into  account  definitions  of  variables  to  constant  values: 

An  :  int. let  %  =  10  in  n*  x  *x  An  :  int  .n  *  100 

Now  consider  the  case  where  instead  of  a  primitive  operation  like  multiplication,  we  call  a  user-defined 
function  with  constant  arguments,  for  example: 

An  :  int .n  *  factorial(5) 

We  could  imagine  a  similar  optimization  of  evaluating  the  call  to  factorial  at  compilation  time  and  re¬ 
placing  it  with  the  result.  Of  course  this  optimization  is  not  safe  in  the  presence  of  side-effects  and  non¬ 
termination,  as  it  changes  the  evaluation  order  of  the  program.  Still  we  can  support  such  an  optimization 
if  we  make  it  a  language  feature:  the  user  can  annotate  a  particular  constant  subexpression  to  be  evaluated 
at  compile-time  and  replaced  by  its  result: 

An  :  int .n  *  {factorial(5)}static  An  :  int .n  *  120 

Compile-time  evaluation  is  thus  a  distinct  static  evaluation  phase  where  annotated  subexpressions  are  eval¬ 
uated  to  completion;  another  way  to  view  this  is  that  the  original  expression  e  is  evaluated  to  a  residual 
expression  or  dynamic  expression  ed  with  all  the  static  subexpressions  replaced;  the  residual  expression  ed 
can  then  be  evaluated  normally  to  a  value.  We  can  also  view  this  as  a  form  of  staged  computation,  where 
the  expression  {factorial(5)}static  produces  code  that  is  to  be  evaluated  at  the  next  stage  -  namely  the 
constant  expression  120. 

This  feature  is  very  useful  in  the  case  of  VeriML  if  instead  of  integer  functions  like  factorial  we  con¬ 
sider  proof  expressions  with  constant  arguments  -  for  example  a  call  to  a  decision  procedure  with  a  closed 
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proposition  as  input.  Note  that  we  mean  ‘closed’  with  respect  to  runtime  dHOL  extension  variables;  it 
can  be  open  with  respect  to  the  normal  logical  variable  environment. 

Xcf) :  ctx.XP  :  \(fr]Prop. 

let  (  V  }  =  {tautology  [P' :  Prop ]  ([P'  :Prop]P  — >-P)}static  in 

{  [<t>]  V/lP/idp  ) . 

Here  the  call  to  tautology  will  be  evaluated  in  the  static  evaluation  phase,  at  the  definition  time  of  this 
function.  The  residual  program  e(i  will  be  a  function  with  a  proof  object  instead: 

Xcf) :  ctx.XP  :  \<f]Prop. 

let  (  V  }  =  (  [P':Prop]  XH  :  P'.H  )  in 

( M  v/ip/idp ) 

The  actual  construct  we  will  support  is  slightly  more  advanced:  we  will  allow  static  expressions  to  be 
bound  to  static  variables  and  also  for  static  expressions  to  depend  on  them.  The  actual  staging  construct 
we  support  is  therefore  written  as  letstatic  %  =  e  in  e' ,  where  %  is  a  static  variable  and  e  can  only  mention 
static  variables.  Returning  to  our  analogy  of  the  {-}static  construct  to  constant  folding,  the  letstatic  con¬ 
struct  is  the  generalization  of  constant  propagation.  An  example  of  its  use  would  be  to  programmatically 
construct  a  proposition  and  then  its  proof: 

Xcf) :  ctx.XP  :  [(f),  x  :  Nat]Prop. 

letstatic  indProp  =  inductionPrincipleStatement  Abt  in 
letstatic  ind  =  inductionPrincipleProof  Nat  indProp  in 


We  now  present  the  formal  details  of  our  staging  mechanism.  Figure  6.14  gives  the  syntax  extensions 
to  expressions  and  contexts,  adding  the  letstatic  construct  and  the  notion  of  static  variables  in  the  context 
T  denoted  as  %  :s  r.  Figure  6.15  gives  the  typing  rules  and  figure  6.16  adapts  the  operational  semantics;  all 
the  syntactic  classes  used  in  the  semantics  are  presented  in  Figure  6.14. 

The  typing  rule  CExp-LetSTATIC  for  the  letstatic  construct  reflects  the  fact  that  only  static  variables 
are  allowed  in  staged  expressions  e  by  removing  non-static  variables  from  the  context  through  the  con¬ 
text  limiting  operation  r|static.  Through  the  two  added  typing  rules  we  see  that  static  evaluation  has  a 
comonadic  structure  with  the  rule  CExp-STATIcVar  corresponding  to  extraction  and  CExp-LetSTATIC 
corresponding  to  iterated  extension  over  all  static  variables  in  the  context. 

The  operational  semantics  is  adapted  as  follows:  we  define  a  new  small-step  reduction  relation  — y 
between  machine  states,  capturing  the  static  evaluation  stage  where  expressions  inside  letstatic  are  evalu¬ 
ated.  If  this  stage  terminates,  it  yields  a  residual  expression  ed  which  is  then  evaluated  using  the  normal 
reduction  relation  — k  With  respect  to  the  first  stage,  residual  expressions  can  thus  be  viewed  as  values. 
Furthermore,  we  define  static  binding  evaluation  contexts  S:  these  are  the  equivalent  of  evaluation  con¬ 
texts  £  for  static  evaluation.  The  key  difference  is  that  static  binding  evaluation  contexts  can  also  go  under 
non-static  binders.  The  reason  is  that  such  binders  do  not  influence  static  evaluation  as  we  cannot  refer  to 
their  variables  due  to  typing. 

A  subtle  point  of  the  semantics  is  that  the  static  evaluation  phase  and  the  normal  evaluation  phase 
share  the  same  state.  The  store  u'  yielded  by  static  evaluation  needs  to  be  retained  in  order  to  evaluate  the 
residual  expression:  (  p  ,  e  )  — (  p! ,  ed  )  — *■*  (  p"  ,  v  ) .  This  can  be  supported  in  an  interpreter-based 
evaluation  strategy,  but  poses  significant  problems  in  a  compilation-based  strategy,  as  the  compiler  would 
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(Expressions)  e  ::=  •  •  •  |  letstatic  %  =  e  in  e' 
(Contexts)  T  ::=  •  •  •  |  T,  x  :s  r 


v 

(Values) 

ed 

(Residual 

expressions) 


S 

(Static  binding 
evaluation 
contexts) 
£s 

(Static 

evaluation 

contexts) 

£ 

(Dynamic 

evaluation 

contexts) 


::=  ()  |  Xx  :  r.ed  \  (v,  v')  |  inj-  v  |  fold  v  \  l  \  Aa  :  k.ed 
\AV:K.ed\(T,ed){V:K)XT 
::=  ()  |  Xx  :  r.ed  \ede'd\x\  (ed,  e')  |  proj-  ed  |  inji  ed 

case(ed,  x.e'd,  x.e'')  |  fold  ed  |  unfold  ed  |  ref  ed  \  ed  :=  e' 
led\l\Aa:  k.ed  \  ed  r  |  fix  x  :  r.ed  \  AV  :K.ed  \  ed  T 
(  T>  ed  )(V:K)xt  I  let  {V>  x)  =  ed\ne'd 
holmatch  T  return  V  :  K.r  with  '1 1  U.T  e'd 

::=  £s  [5]  |  letstatic  %  =  •  in  e'  \  letstatic  %  =  S  in  e' 

Xx  :  r.S  |  case(e^,  x.S,  x.e2 )  |  case(e^,  x.ed,  x.S ) 

Acc :  k.S  |  fix  x  :  r.S  |  XV  :  K.S  \  let  (  V,  x  )  =  ed  in  S 
holmatch  T  return  V  :  K.r  with  '1 1  U.T  >->  S 

::=  £s  e'  I  ed  £s  I  (£s>  e )  I  ( ed>  £s)  I  Pr°Ji  £s  I  inJi  £s 

case(£s,  x.e1,  x.e-,)  \  fold  £s  \  unfold  £s  \  ref  £s  \  £s  :=  e' 

ed  ■=£s\\£s\£s't\£sT\(T’  £s  )(V:K)xt 
let  (  V,  x  )  =  £s  in  e' 

■■■■=•  \£ed\v£\(£,  ed)  |  0,  £)  |  proj;  £  \  inj,  £ 

case(£,  x.e '  x.e",)  I  fold  £  I  unfold  £  I  ref  £  I  £  :=  e d 
v:=£\\£\£t \£T\(T,£){V:K)xt 
let  (  V,  x  )  =  £  in  ed 


Figure  6.14:  VeriML  computational  language:  Staging  extension  (syntax) 


'F;  A4;  T  h  e  :  r 


•;  A4;  T  ■  \~e:r  M;  :  r  h  e  :  r  x  :  t  ET 

- 1= - - - CExp-LetStatic  - - - CExp-StaticVar 

\F;  A4;  T  h  letstatic  %  =  e  in  e  :  t  'F;  A4;  T  V  x  :  r 


F | static  =  ( Limiting  a  context  to  static  variables) 


I  static 

(F,  X  . $  ?  )  |  static 

(r,  X  .  t )  |  static 

(r,  a  .  ^  )  |  static 


I  static’ 
I  static 
I  static 


%  :  t 


Figure  6.15:  VeriML  computational  language:  Staging  extension  (typing) 
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( f*  >  e  )  — (  /i ,  e'  ) 


(V’ed)  — * 
(lu,S[ed]  )  — ♦, 

( fj  ,  <S[letstatic  x  =  v  in  e]  ) 

(  /j  ,  letstatic  x  =  v  in  e  ) 


- - -  Op-StaticEnv 

(  /  •  5[<]  ) 

— *s  ( fj  ,  S[e[v/x ]] )  Op-LetStaticEnv 
— ( fj  ,  e\v/x\ )  Op-LetStaticTop 


Figure  6.16:  VeriML  computational  language:  Staging  extension  (operational  semantics) 


need  to  yield  an  initial  store  together  with  the  executable  program.  In  practice,  we  get  around  this  problem 
by  allowing  expressions  of  only  a  small  set  of  types  to  be  statically  evaluated  (e.g.  allowing  /HOL  tuples 
but  disallowing  functions  or  mutable  references);  repeating  top-level  definitions  during  static  and  normal 
evaluation  (so  that  an  equivalent  global  state  is  established  in  both  stages);  and  last  we  assume  that  the 
statically  evaluated  expressions  preserve  the  global  state.  We  will  comment  further  on  this  issue  when  we 
cover  the  VeriML  implementation  in  more  detail,  specifically  in  Subsection  8.3.3.  As  these  constraints  are 
not  necessary  for  type-safety,  we  do  not  capture  them  in  our  type  system;  we  leave  their  metatheoretic 
study  to  future  work. 


Metatheory 

We  will  now  establish  type-safety  for  the  staging  extension  by  proving  progress  and  preservation  for  eval¬ 
uation  of  well-typed  expressions  e  through  the  static  small-step  semantics.  Type-safety  for  the  normal 
small  step  semantics  (  /a  ,  ed  )  — *■  (  p! ,  e'd  \  is  entirely  as  before,  as  residual  expressions  are  identical  to 
the  expressions  of  the  previous  section  and  the  relation  — *  has  not  been  modified. 

Lemma  6.3.1  (Extension  of  Lemma  6.1.4)  (Computational  substitution) 

L  T;  T,  a'T'T'hrT  'L;rbT/:&/  %  'L/;  M;  T,  a  :  k\  T1  b  e  :  r  T;  T  V  t  :k' 

1. -  2. - 

T,  'L/;  L,  b  t\t  /  a  \  :  k  T,  'L/;  M.;  L,  / a'\  b  e[r ' /a  \  :  t\t'  !a'\ 


3. 


T,  T7;  M.;  T,  x  :  r,  Y'  \~  ed:r  T;  A4;  Y  b  e'd  :  r' 
T,  T';  M;  L,  Y' \~  ed[e', / x']  :t 


T;  T,  x  :  r,  r;  b  e  :  r' 


*;  A4;  •  b  v  :  r 


$;  f,  x  :  t,  b  b  e  :  r 


*;  M;  •  b  v  :  r 


T;  M;  L,  L;  b  e[f/x]  :  r' 


T;  M;  L,  L;  b  e[f/x]  :  r' 


T,  T/  b  L,  a  :  k! \  L;  wf  T;  T  b  r  :  k' 

T,  'L/  b  L,  L/[r/ /a!~\  wf 

Proof.  By  induction  on  the  typing  derivation  for  t,  e  or  ed.  We  prove  the  cases  for  the  two  new  typing 
rules,  cases  follow. 
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Part  3.  Case  CExp-StaticVar. 


/  x:sreT  \ 

y'P;  Ad;  Y  b  x  :  r  J 

We  have  that  [e^/x]  =  e'd,  and  \P;  Ad;  T  h  ed:r  ,  which  is  the  desired. 

Case  CExp-LetStatic. 

/ •;  M;  r|static  h  e  :  t  T;  Ad;  T,  x  :s 
\  'P;  Ad;  T  h  letstatic  x  —  e  in  e' :  t  ) 

Impossible  case  by  syntactic  inversion  on  ecj . 


Part  4.  Case  CExp-LetStatic. 

/ •;  M;  r[statk,  %  :  r,  I^arie  h  e  :  T  V;  M;T,  x  :s  t,T' ,  x'  :s 
\  'P;  Ad;  T,  x  :s  r,  b  letstatic  x  =  e  in  e  :  f 


We  use  part  5  for  e  to  get  that  •;  Ad;  r|static,  r'|static  b  e[v/x\  :  r 
By  induction  hypothesis  for  e'  we  get  'P;  Ad;  T,  T'  ,x'  :s  t"  h  e'\y  /x ]  :  U 
Thus  using  the  same  typing  rule  we  get  the  desired  result. 


Lemma  6.3.2  (Types  of  decompositions) 


1. - 

3rh( 


_ *P;  Ad;  £KS[e]  :  t  T\statlc  =  * _ 

•;  Ad;  •  h  e  :  f  Veh»;  Ad;  thd  :t/=>'P;  Ad;  T  b  5|V]  :  r  ) 


2. - 

3rh(  T;  Ad;  T  b  e  :  t/ 


\P;  Ad;  rbfs[e]:i 

Ve.\P;  Ad;  Tbb  :/=>■$;  Ad;  T  b  Ss  [cj/]  :  r  ) 


□ 


Proof. 

Part  1.  By  structural  induction  on  S. 

Case  S  =  letstatic  x  =  •  in  eh 

By  inversion  of  typing  we  get  that  •;  Ad;  T|static  b  e  :  t.  We  have  r|static  =  •,  thus  we  get  •;  Ad;  •  b  e  :  x' . 
Using  the  same  typing  rule  we  get  the  desired  result  for  <S[V]. 

Case  S  =  letstatic  x  =  S'  in  e".  Directly  by  inductive  hypothesis  for  S'. 

Case  S  =  £s[«S].  We  have  that  \P;  Ad;  T  b  £s [<5 [e^ ] ]  :  r.  Using  part  2  for  Ss  and  <S[e^]  we  get  that 
\P;  Ad;  T  b  :  x'  for  some  x'  and  also  that  for  all  e'  such  that  \P;  Ad;  T  b  e  :  x'  we  have  \P;  Ad;  T  b 

£s  [ e ']  :  r.  Then  using  induction  hypothesis  we  get  a  x"  such  that  •;  Ad ;  •  b  ec{ :  x".  For  this  type,  we  also 
have  that  •;  Ad;  •  b  e'  :  x"  implies  T;  Ad;  T  b5[d(]  :  x',  which  further  implies  \P;  Ad;  T  b  £$  [5[VJ]  :  x. 
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Part  2.  By  induction  on  the  structure  of  £s.  In  each  case,  we  use  inversion  of  typing  to  get  the  type  for 
e  and  then  use  the  same  typing  rule  to  get  the  derivation  for  £$  [V].  □ 

Theorem  6.3.3  (Extension  of  Theorem  6.1.5)  (Preservation) 

•;  M;  •  \~e\T  (y,e) — >s(y',e')  /a  ~  M 

1. - 

3AI/.(  •;  M);  •  h  e  :  r  M.  C  M!  /a'  ~  M.'  ) 

•;  M;  •  h  ed  :  t  (p,ed)  — »  (  y  ,  e'd  )  y  ~  M 

•;A4/;»he^:r  y  ~  M!  ) 

Proof. 

Part  1.  We  proceed  by  induction  on  the  derivation  of  (  y ,  e  )  — *s  ( y' ,  e' ). 

Case  Op-StaticEnv. 

(  P  .  ed  )  —  (  P  .  ^  ) 

_(/“»  5I>J)  — L  (V  >  5l>j])_ 

Using  Lemma  6.3.2  we  get  •;  A4;  »  h  ^  :  rh  Using  part  2,  we  get  that  •;  Ai;  •  h  :  r'.  Using  the 
same  lemma  again  we  get  the  desired. 

Case  Op-LetStaticEnv. 

[(  y  ,  5[letstatic  %  =  v  in  e] )  — *s  (  y  ,  5[e[U/x]]  )] 

Using  Lemma  6.3.2  we  get  •;  A4;  •  h  letstatic  %  =  v  in  e  :  r'.  By  typing  inversion  we  get  that 
•;  A4;  •  b  v  :  x"  and  also  that  •;  Af;  %  :s  t"  h  e  :  r1.  Using  the  substitution  lemma  (Lemma  6.3.1) 
we  get  the  desired  result. 

Case  Op-LetStaticTop. 

[(  y  ,  letstatic  x  =  vine)  — >s  (  y  ,  e\v /x\  )] 

Similar  to  the  above. 

Part  2.  Exactly  as  before  by  induction  on  the  typing  derivation  for  ed,  as  ed  entirely  matches  the  defini¬ 
tion  of  expressions  prior  to  the  extension.  □ 

Lemma  6.3.4  (Unique  decomposition) 

1.  Every  expression  e  is  either  a  residual  expression  ed  or  there  either  exists  a  unique  decomposition  e  = 

S[ed\ 

2.  Every  residual  expression  ed  can  he  uniquely  decomposed  as  ed  =  £\v\ 

Proof. 
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Part  1.  By  induction  on  the  structure  of  the  expression  e.  We  give  some  representative  cases. 

Case  e  =  dV  :  K.e  .  Splitting  cases  on  whether  e'  =  e'd  or  not.  If  e'  —  e'd  then  trivially  e  =  ed.  If  e'  f  e'd 
then  by  induction  hypothesis  we  get  a  unique  decomposition  of  e'  into  «S/[e//].  The  original  expression 
e  can  be  uniquely  decomposed  as  S[e"]  with  S  =  XV  :  K.S' .  This  decomposition  is  unique  because  the 
outer  frame  is  uniquely  determined;  the  uniqueness  of  the  inner  frames  and  the  expression  filling  the  hole 
are  already  established  by  induction  hypothesis. 

Case  e  =  ex  T.  By  induction  hypothesis  we  get  that  either  e'  —  e'd,  or  there  is  a  unique  decomposition  of 
e'  into  «S/[e//].  The  former  case  is  trivial.  In  the  latter  case,  e  is  uniquely  decomposed  using  S  =  £s  [6V] 
with  £s  =  •  T,  into  e  =  «S/[e//]  T . 

Case  e  =  (let  (  e',  V  )  =  x  in  e").  Using  induction  hypothesis  on  e';  if  it  is  a  residual  expression,  then 
using  induction  hypothesis  on  e";  if  that  too  is  a  residual  expression,  then  the  original  expression  e  is 
too.  Otherwise,  use  the  unique  decomposition  of  e"  =  S' [ew/]  to  get  the  unique  decomposition  e  = 
let  (  e^,  x  )  =  S' [e/x/]  in  .  If  e'  is  not  a  residual  expression,  use  the  unique  decomposition  of  e'  =  S"\_e""~\ 
to  get  the  unique  decomposition  e  =  let  (  S"\_e""~\,  x  }  =  e"  in  . 

Case  e  =  letstatic  x  =  e/  in  e".  Using  the  induction  hypothesis  on  e’ . 

In  the  case  that  e'  —  ej,  then  trivially  we  have  the  unique  decomposition 
e  =  (letstatic  x  =  •ine//)[e^]. 

In  the  case  where  e'  =  <S[e^],  we  have  the  unique  decomposition 
e  =  (letstatic  x  =  S  in  e//)[e^]. 

Part  2.  Similarly,  by  induction  on  the  structure  of  the  dynamic  expression  ed.  □ 

Theorem  6.3.5  (Extension  of  Theorem  6.1.7)  (Progress) 

•;  M;  •  h  e :  r  y.  ~  M  e^ed  ^•;M;»\~ed:r  y  ~  M  ed^v 

3y',e'.(y,e) — >s(y',e')  3y' ,e'd.  (  y  ,  ed) — >(y',e'd) 

Proof. 

Part  1  First,  we  use  the  unique  decomposition  lemma  (Lemma  6.3.4)  for  e.  We  get  that  either  e  is  a 
dynamic  expression  ed,  in  which  case  we  are  done;  or  a  decomposition  into  <S[e^].  In  that  case,  we  use 
Lemma  6.3.2  and  part  2  to  get  that  either  e'd  is  a  value  or  that  some  progress  can  be  made.  In  the  latter 
case  we  have  (  y  ,  e'd  )  — *■  (  y' ,  ej  \  for  some  y' ,e'd-  Using  Op-STATIcEnv  we  get  (  y  ,  <S[e^]  )  — >5 
^  y' ,  <S[eJ]  thus  we  have  the  desired  for  e'  =  5[eJ],  In  the  former  case,  where  e  =  5[v],  we  split  cases 
based  on  whether  S  =  (letstatic  %  =  •  in  e)  or  not;  in  the  former  case  we  use  Op-LetSTATIcTop  and  in 
the  latter  the  rule  Op-LetSTATIcEnv  to  make  progress. 

Part  2  Identical  as  before.  □ 

Theorem  6.3.6  (Extension  of  Theorem  6.1.8)  (Type  safety  for  VeriML) 
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►;  A4;  •  h  e  :  r  y  ~  A4 


1 -ed 


3y',M',  e'.(  ( y,e ) — *s  (  y  ,  e  )  •;  Ai';  •  b  e  :  t  y!  ~  M1  ) 

•;  -A4;  *\~  ed:r  ^  ~  7W  edfv 
3y',M',e'd.(  ( y  ,  e) — ►  (  y ,  e'  )  •;  Ad';  •  h  e'  :  r  y  ~  M1  ) 

Proof.  Directly  by  combining  Theorem  6.3.3  and  Theorem  6.3.5. 


□ 


6.4  Proof  erasure 

Consider  the  following  program: 

tautology  [P  :Prop,Q  :  Prop ]  ((P  A  Q)  — *■  (Q  AP)) :  ([P,  Q]  (P  A  Q)  — *■  (Q  AP)) 
assuming  the  following  type  for  the  tautology  tactic: 

tautology  :  (<^> :  ctx)  —*■  (P  :  [<^>]Prop)  — *■  ([<^>]  P) 

where  it  is  understood  that  the  function  throws  an  exception  in  cases  where  it  fails  to  prove  the  given 
proposition.  This  program  can  be  seen  as  a  proof  script  that  proves  the  proposition  (P  A  Q)  — *  (Q  A  P).  If 
it  evaluates  successfully  it  will  yield  a  proof  object  for  that  proposition.  The  proof  checker  for  /HOL  is 
included  in  the  type  system  of  VeriML  and  therefore  we  know  that  the  yielded  proof  object  is  guaranteed 
to  be  valid  -  this  is  a  direct  consequence  of  type  safety  for  VeriML.  There  are  many  situations  where  we 
are  interested  in  the  exact  structure  of  the  proof  object.  For  example,  we  might  want  to  ship  the  proof 
object  to  a  third  party  for  independent  verification.  In  most  situations  though,  we  are  interested  merely  in 
the  existence  of  the  proof  object.  In  this  section  we  will  show  that  in  this  case,  we  can  evalute  the  original 
VeriML  expression  without  producing  proof  objects  at  any  intermediate  step  but  still  maintain  the  same 
guarantees  about  the  existence  of  proof  objects.  We  will  do  this  by  showing  that  an  alternative  semantics 
for  VeriML  using  proof  erasure  simulate  the  normal  semantics  -  that  is,  if  we  erase  all  proof  objects  from 
an  expression  prior  to  execution,  the  expression  evaluates  through  exactly  the  same  steps. 

Evaluating  expressions  under  proof  erasure  results  in  significant  space  savings,  as  proof  objects  can 
become  very  large.  Still,  there  is  a  trade-off  between  the  space  savings  and  the  amount  of  code  that  we 
need  to  trust.  If  we  evaluate  expressions  under  the  normal  semantics  and  re-validate  the  yielded  proof 
objects  using  the  base  proof  checker  for  /HOL,  the  proof  checker  is  the  only  part  of  the  system  that  we 
need  to  trust,  resulting  in  a  very  small  trusted  base.  On  the  other  hand,  if  we  evaluate  all  expressions  under 
proof  erasure,  we  need  to  include  the  implementation  of  the  whole  VeriML  language  in  our  trusted  base, 
including  its  type  checker  and  compiler.  In  our  implementation,  we  address  this  trade-off  by  allowing 
users  to  selectively  evaluate  expressions  under  proof  erasure.  In  this  case,  the  trusted  core  is  extended  only 
with  the  proof-erased  version  of  the  “trusted”  expressions,  which  can  be  manually  inspected. 

More  formally,  we  will  define  a  type-directed  translation  from  expressions  to  expressions  with  all 
proofs  erased  J'L;  Ad;  T  h  e:rJE  =  e/.  We  will  then  show  a  strict  bisimulation  between  the  normal  se¬ 
mantics  and  the  semantics  where  the  erasure  function  has  first  been  applied  -  that  is,  that  every  evaluation 
step  under  the  normal  semantics  (  y  ,  e  )  — ►  (  y' ,  e' )  is  simulated  by  a  step  like  (  [[^]]£  ,  [[ejf  )  — ► 
(  e  ’  Ee/J  E  )  ’  anc^  a^so  t^iat  t^ie  inverse  holds.  The  essential  reason  why  this  bisimulation  exists  is 
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that  the  pattern  matching  construct  we  have  presented  does  not  allow  patterns  for  individual  construc¬ 
tors  of  proof  objects  because  of  the  sort  restrictions  in  the  pattern  typing  rules  (Figures  5.1  and  5.2).  Since 
pattern  matching  is  the  only  computational  construct  available  for  looking  into  the  structure  of  proof 
objects,  this  restriction  is  enough  so  that  proof  objects  will  not  influence  the  runtime  behavior  of  VeriML 
expressions. 

We  present  the  details  of  the  proof  erasure  function  in  Figure  6.17.  It  works  by  replacing  all  proof 
objects  in  an  expression  e  by  the  special  proof  object  admit,  directly  using  the  erasure  rule  for  extension 
terms  EraseProof.  We  only  show  the  main  rules;  the  rest  of  the  cases  only  use  the  erasure  procedure 
recursively.  In  the  same  figure,  we  also  show  how  the  same  function  is  lifted  to  extension  substitutions 
<jq  and  stores  /a  when  they  are  compatible  with  the  store  typing  context  M .  We  call  the  term  admit  the 
prove-anything  constant  and  it  is  understood  as  a  logic  constant  that  cannot  be  used  by  the  user  but  proves 
any  proposition.  It  is  added  to  the  syntax  and  typing  of  dHOL  in  Figure  6.18. 

We  first  prove  the  following  auxiliary  lemmas  which  capture  the  essential  reason  behind  the  bisimulation 
proof  that  follows. 

Lemma  6.4.1  (Proof  object  patterns  do  not  exist) 

s  f.  Prop 

Proof.  By  structural  induction  on  the  pattern  typing  for  Tp.  □ 

Lemma  6.4.2  (Pattern  matching  is  preserved  under  proof  erasure) 

.\*p*u>TP:K  .\~T:K  [[.h  T:K]E  =  TE 

(rP~r)  =  (rP~r£) 

Proof.  We  view  the  consequence  as  an  equivalence:  Tp  ~  T  =  0*  4=>  Tp  ~  TE  =  .  We  prove  each 

direction  by  induction  on  the  derivation  of  the  pattern  matching  result  and  using  the  previous  lemma.  □ 

Lemma  6.4.3  (Erasure  commutes  with  extension  substitution  application) 

1  tt'h  ayi*  []>;$h  t:fJ£  =  tE  =  ^ 

tE  •  =  ['P/;  $  •  F  t  ■  :  f  •  a* ]  £ 

^\~T  :K  |vPh  T:KJE  =  TE  h  ^  £  =  aE 

2'  TE-aE=  \~  T  ■  :  K  ■  £ 

'F;  M;  The  :  r  'P/  h  :  'P  [['P;  M;  T  b  e  :  =  eE  [['P'  h  :  'P]  £  =  aE 

eE  ■  M;  T  •  (7^  h  e  ■  :  r  ■  ]  £ 

Proof.  By  induction  on  the  structure  of  T.  □ 

We  are  now  ready  to  prove  the  bisimulation  theorem. 
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\P;  $  b  t  :  t  \P;  $  b  t  ’.Prop 

- - - — - : - EraseProof 

[['P;  $  b  t  :  t  ]]  £  =  admit 


-.KJe  =  Te 

['P;  t:t'JE  =  tE 

['Pb[<D]t:[<P]  i']]£  =  [$]  tE  ppR$]  $,:[$]rt%]£=[$]  $' 

['P'  b  a*  :  'P]  £  =  aE 

_  l*'\-*9:*JE  =  4  l*'\-T:K.g9JE  =  TE 

[vp'b.:.]£  =  .  V:T):(V,  V:K)J£  =  (aE,  TE) 

C'P ;  M’,T  \~  e  t~^e=  eE 

I*,  V’.K’M’,Y^e’.rJE  =  eE 
[['P;  M;  T  b  (XV  :  K.e) :  ((V  :  K)  -+  t)]|£  =  XV  :  K.eE 


l'Y’,M’,YYe’.(V’.K)-^T]E=eE  1*\-T:KJE  =  TE 

Pb  M;  Y  b  e  T  :  r  •  («f*,  T/V) J£  =  e£  TE 


[Pbr:I]£  =  T£  l*;  M;  Y  b  e  :  t  •  (id9,  T/VJh  =  ^ 
[®i  M- r  I-  <  T.  e  )(V[K)„  :  ((V  :K)  X  r)]  £  =  (  TE ,  eE  ) ^ 


[['P;  M;  YYe:(V  :K)xTjE  =  eE  ['P,  V:K;M ;  Y,  x  :  r  b  e' :  r]  £  =  e/£ 
[['P;  A4;  T  b  let  (  V,  %  }  =  e  in  e  :  A]]  £  =  (let  (  V,  x  )  =  eE  in  elE) 

l'H^T’.K]E  =  TE  [<P)$,;Mrbe/:T.(4  TP/y)]£  =  e/£ 


T  ,  .  holmatch  T  return  V  :K.r 
'P;  A4;  T  b  ,  :t-  (tdy,  TV  )  +  umt 

with  'P u-TP^e  w  ji£ 

=  holmatch  TE  return  V  :A.t  with  ^ „-TP  >-*■  e 


IE 


M  £  =  b' 


when  pi  ~  M 


MU 


=  • 


[[•;  A4;  •  b  v  :  t]£  =  vE 
l/u,  (l^v)JE  =  fj,  (l^vE) 


Figure  6.17:  Proof  erasure  for  VeriML 
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t  ::=  •  •  •  I  admit 


'I7;  $  h  t  :  Prop 

- ; — -  ProveAnything 

\P;  $  h  admit :  t 


Figure  6.18:  Proof  erasure:  Adding  the  prove-anything  constant  to  dHOL 

Theorem  6.4.4  (Proof  erasure  semantics  for  VeriML  are  bisimilar  to  normal  semantics) 

•;A4;*he:r  (u~A4  (pi,e) — >(Kp,e/) 

[[•;  M;  •\~e:TjE  =  eE  [•;  M;  •  h e  :  t] £  =  e'E  Q>]]£  =  jP 

•;  A4;  •  h  e  :  r 

p~M  [.;A4;.he:T]£  =  e£  ME  =  pE  (  /  ,  e£  )  — >  (  y!E  ,  e'E  ) 

•;  M!  \  •  h  e  :  r  /u/~A4/  M.  C  M( 

[•!  M'\  •he/:r]£  =  e/£  [/u/]£  =  (u/£  (  p  ,  e  ) — >(p,e) 

Proof.  Part  1.  By  induction  on  the  step  relation  (  p  ,  e  )  — ►  (  p  ,  e' ) .  In  all  cases  the  result  follows 
trivially  using  Lemmas  6.4.2  and  6.4.3. 

Part  2.  By  induction  on  the  step  relation  (  pE  ,  eE  )  — ►  (  p'E  ,  e'E  ).  We  prove  three  representative 
cases. 

Case  Op-IIHol-Beta. 

[  (  PE  ,  (XV  :  K.e,E )  TE  )  —  (  pE  ,  e'E  •  ( TE/V )  )  ] 

By  inversion  of  [[•;  A4;  •  h  e  :  t|£  =  ( XV  :  K.e'E)  TE  we  get  that  e  =  (dV  :  K.e")  T  with 
[[  V  :  K;  M.',  •  h  e"  :  (V  :  K)  — >  tx]]  e  =  e'E  and  [[*1-7:  AJ£  =  TE .  Choosing  e'  —  e"  •  ( T / V ),  p'  =  pE 
and  M!  =  M.  we  have  the  desired,  using  Lemma  6.4.3. 

Case  Op-HolMatch. 

_ TP~TE  =  aE _ 

(  pE  ,  holmatch  TE  with  'Pa.TP  e'E  )  — ►  (  pE  ,  i nj x  ( e'E  ■  aE)  ) 

By  inversion  of  [[•;  A4;  •  h  e  :  tJ£  =  eE  for  eE  =  holmatch  TE  with  ^  U-TP  >— ►  e/£  we  get  T  and  e"  such 
that  e  =  (holmatch  T  with  ^  H-TP  >-*  e")  with  [[•  h  T  :  AJ£  =  TE  and  [['P„;  A4;  •  h  e"  :  t7]]  E  =  e/E . 
By  Lemma  6.4.2  we  get  that  Tp  ~  T  =  aE  with  =  aE.  Thus  setting  e'  =  i nj  1(e//  •  aE)  and  using 
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Lemma  6.4.3  we  get  the  desired. 
Case  Op-NewRef. 


“'(/  ^E) 

(  fj.E  ,  ref  vE  )  — *  (  (//,  l^vE),l) 


By  inversion  of  [[•;  At;  •  h  e  :  t|  e  =  ref  vE  we  get  a  value  v  such  that  [[•;  A4;  »\~  v  \  t7]]  e  =  ve .  There¬ 
fore  setting  /j'  =  (/j,  l  <-*v)  we  get  the  desired.  □ 
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Chapter  7 

User-extensible  static  checking 


The  type  system  of  the  VeriML  computational  language  includes  the  dHOL  type  system.  This  directly 
means  that  proof  objects  within  VeriML  expressions  and  tactics  that  are  automatically  checked  for  logical 
validity.  As  we  argued  in  Chapter  2,  this  is  one  of  the  main  departure  points  of  VeriML  compared  to 
traditional  proof  assistants.  Yet  we  often  need  to  check  things  beyond  logical  validity  which  the  VeriML 
type  system  does  not  directly  allow. 

A  common  example  is  checking  whether  two  propositions  or  terms  are  equivalent.  This  check  re¬ 
quires  proof  search:  we  first  need  to  find  a  proof  object  for  the  equivalence  and  then  check  it  for  validity 
using  the  VeriML  type  system.  Yet  such  equivalence  checks  are  very  common  when  writing  dHOL 
proofs;  we  would  like  to  check  them  statically,  as  if  they  were  part  of  type  checking.  In  this  way,  we  will 
know  at  the  definition  time  of  proof  scripts  and  tactics  that  the  equivalence  checks  contained  in  proofs 
are  indeed  valid.  Checks  involving  proof  search  are  undecidable  in  the  general  case,  thus  fixing  a  search 
algorithm  beforehand  inside  the  type  system  will  not  be  able  to  handle  all  equivalence  checks  that  users 
need  in  an  efficient  way.  Users  should  instead  be  able  to  provide  their  own  search  algorithms.  We  say 
that  static  checking  -  checks  that  happen  at  the  definition  time  of  a  program,  just  as  typing  -  should  be 
user-extensible.  In  this  chapter  we  will  show  that  user-extensible  static  checking  is  possible  for  proofs  and 
tactics  written  in  VeriML;  we  will  also  briefly  present  how  the  same  technique  can  be  viewed  as  a  general 
extensible  type  checking  mechanism,  in  the  context  of  dependently-typed  languages. 

In  order  to  make  our  description  of  the  issue  we  will  address  more  precise,  let  us  consider  an  example. 
Consider  the  following  logical  function: 

twice  :  Nat  — >  Nat  =  Ax  :  Nat.x  +  x 

Given  the  following  theorem  for  even  numbers: 

evenMultl  :  V %  :  Nat. even  (lx) 

we  want  to  prove  the  following  proposition: 

evenTwice  :  Vx  :  Nat. even  (twice  x) 

In  normal  mathematical  practice,  we  would  be  able  to  say  that  evenTwice  follows  directly  from  evenMultl. 
Though  this  is  true,  a  formal  proof  object  would  need  to  include  more  details,  such  as  the  fact  that  x  +  x  = 
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Figure  7.1:  Layers  of  static  checking  and  steps  in  the  corresponding  formal  proof  of  even  { twice  x) 


2x,  the  /3-reduction  that  reduces  twice  x  to  x  +  x  and  the  fact  that  if  even{2x)  is  true,  so  is  even(x  +  x ) 
since  the  arguments  to  even  are  equal  (called  congruence).  The  formal  proof  is  thus  roughly  as  follows1: 

even  (2%)  (theorem) 

twice  x  =  x  +  x  (/3-conversion) 

x  +  x  =  2x  (arithmetic  conversion) 

even  {twice  x)  =  even  (2%)  (congruence) 

even  {twice  x)  (follows  from  the  above) 

We  can  extend  the  base  dHOL  type  system,  so  that  some  of  these  equivalences  are  decided  automati¬ 
cally;  thus  the  associated  step  of  the  proof  can  be  omitted.  This  is  done  by  including  a  conversion  rule  in 
dHOL,  as  suggested  in  Section  3.2,  which  can  be  viewed  as  a  fixed  decision  procedure  that  directly  handles 
a  class  of  equivalences.  For  example,  including  a  conversion  rule  that  automatically  checks  /3-equivalence 
would  allow  us  to  omit  the  second  step  of  the  above  proof.  As  more  checks  are  included  in  the  dHOL 
logic  directly,  smaller  proofs  are  possible,  as  shown  in  Figure  7.1.  Yet  there  is  a  tradeoff  between  the  so¬ 
phistication  of  the  conversion  rule  included  in  the  logic  and  the  amount  of  trust  we  need  to  place  in  the 
logic  metatheory  and  implementation.  Put  otherwise,  there  is  a  tradeoff  between  the  size  of  the  resulting 
proofs  and  the  size  of  the  trusted  core  of  the  logic.  Furthermore,  even  if  we  include  checking  for  all  steps 
-  /3-conversion,  arithmetic  conversion  and  congruence  -  there  will  always  be  steps  that  are  common  and 
trivial  yet  the  fixed  conversion  rule  cannot  handle.  The  reason  is  that  by  making  any  fixed  conversion  rule 
part  of  the  logic,  the  metatheory  of  the  logic  and  the  trust  we  can  place  in  the  logic  checker  are  dependent 
on  the  details  of  the  conversion  rule,  thus  disallowing  user  extensions.  For  example,  if  we  later  prove  the 
following  theorem: 

Vx,even  x  —*■  odd  {x  +  1) 

we  can  use  the  above  lemma  evenTwice  to  show  that  odd  {twice  x  +  1).  Yet  we  will  need  to  allude  to 
evenTwice  explicitly,  as  the  fixed  conversion  rule  described  does  not  include  support  for  proving  whether 
a  number  is  even  or  odd. 

1.  We  are  being  a  bit  imprecise  here  for  presentation  purposes.  All  three  equalities  would  actually  hold  trivially  through 
the  conversion  rule  if  definitional  equality  includes  (3-  and  i— reduction.  Yet  other  cases  of  arithmetic  simplification  such  as 
x  +  x  —  x  -  2  would  not  hold  directly.  Supporting  the  more  general  case  of  simplification  based  on  arithmetic  properties  is 
what  we  refer  to  in  this  chapter  when  referring  to  an  arithmetic  conversion  rule.  Similarly,  conversion  with  congruence  closure 
reasons  about  arbitrary  equality  rewriting  steps  taking  the  available  hypotheses  into  account.  Thus  it  is  more  general  than  the 
congruence  closure  included  in  definitional  equality,  where  simply  definitionally  equal  subterms  lead  to  definitionally  equal 
terms. 
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A  different  approach  is  thus  needed,  where  user  extensions  to  the  conversion  rule  are  allowed,  leading 
to  proofs  that  omit  the  trivial  details  that  are  needed  even  in  user-specified  domains.  This  has  to  be  done  in 
a  safe  manner:  user  extensions  should  not  introduce  equivalences  that  are  not  provable  in  the  original  logic 
as  this  would  directly  lead  to  unsoundness.  Here  is  where  the  VeriML  type  system  becomes  necessary:  we 
can  use  the  rich  typing  offered  by  VeriML  in  order  to  impose  this  safety  guarantee  for  user  extensions.  We 
require  user  extensions  to  provide  proof  for  the  claimed  equivalences  by  expecting  them  to  obey  a  specific 
type,  such  as  the  following: 

userExtension  :  {tx  :  T)  — »  ( t2  :  T)  — >  {tx  =  tf 

VeriML  is  an  expressive  language,  allowing  for  a  large  number  of  such  extensions  to  be  implemented.  This 
includes  the  equivalence  checkers  for  /3-conversion,  congruence  closure  as  well  as  arithmetic  simplifica¬ 
tions.  Thus  none  of  these  need  to  be  included  inside  the  logic  -  they  can  all  be  implemented  in  VeriML 
and  taken  outside  the  trusted  core  of  the  system.  Based  on  this  idea,  we  will  present  the  details  of  how 
to  support  a  safe  and  user-extensible  alternative  to  the  conversion  rule  in  Section  7.1,  where  conversion  is 
implemented  as  a  call  to  tactics  of  a  specific  type.  We  have  implemented  a  version  of  the  conversion  rule 
that  includes  all  the  equivalence  checkers  we  have  mentioned.  Supporting  these  has  previously  required  a 
large  metatheoretic  extension  to  the  CIC  logic  and  involved  significant  reengineering  effort  as  part  of  the 
CoqMT  project  [Strub,  2010], 

So  far  we  have  only  talked  about  using  the  conversion  rule  as  part  of  proof  objects.  Let  us  now 
consider  what  user-extensible  checking  amounts  to  in  the  case  of  tactics.  Imagine  a  tactic  that  proves 
whether  a  number  is  even  or  odd. 

evenOrOdd  :  (</> :  ctx )  — >  ( n  :  Nat )  — *■  (even  n )  +  ( odd  n) 

The  cases  for  2x  and  twice  x  would  be: 

evenOrOdd  </>  n  =  holmatch  n  with 

2x  inj,  (evenMult2  x  ) 

twice  x  !-*■  injj  /•••:  even  {twice  x)  \ 


In  the  case  of  twice  x,  we  can  directly  use  the  evenTwice  lemma.  Yet  this  lemma  is  proved  through  one 
step  (the  allusion  to  evenMult2  x)  when  the  conversion  rule  includes  the  equivalence  checkers  pictured 
in  Figure  7.1.  We  would  rather  avoid  stating  and  proving  the  lemma  separately,  alluding  instead  to  the 
evenMult2  x  theorem  directly,  even  in  this  case,  handling  the  trivial  rewriting  details  through  the  con¬ 
version  rule.  That  is,  we  would  like  proofs  contained  within  tactics  to  be  checked  using  the  extensible 
conversion  rule  as  well.  Furthermore,  these  checks  should  be  static  so  as  to  know  as  soon  as  possible 
whether  the  proofs  are  valid  or  not.  As  we  said  above,  the  conversion  rule  amounts  to  a  call  to  a  VeriML 
tactic.  Therefore  we  need  to  evaluate  the  calls  to  the  conversion  rule  statically,  at  the  definition  time  of 
tactics  such  as  evenOrOdd.  We  achieve  this  by  making  critical  use  of  two  features  of  VeriML  we  have 
already  described:  the  staging  extension  of  Section  6.3  and  the  collapsed  logical  terms  of  Section  5.2. 

The  essential  idea  is  to  view  static  checking  as  a  two-phase  procedure:  first  the  normal  VeriML  type- 
checker  is  used;  then,  during  the  static  evaluation  phase  of  VeriML  semantics,  additional  checks  are  done. 
These  checks  might  involve  arbitrary  proof  search  and  are  user-defined  and  user-extensible,  through  nor¬ 
mal  VeriML  code.  In  this  way,  proofs  contained  within  tactics  can  use  calls  to  powerful  procedures,  such 
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evenOrOdd  <f>  n  —  holmatch  n  with 

2x  injj  (  evenMult2  x  ) 
twice  x  i  nj  [  ( evenMult2  x  ) 


fixed 

type  checking 


extensible 
static  checking 


VeriML  type  system 
(including  dHOL) 


congruence  closure  +  •  •  • 


/3-conversion  +  •  •  • 


arithmetic  +  •  •  • 


Figure  7.2:  User-extensible  static  checking  of  tactics 

as  the  conversion  rule,  yet  be  statically  checked  for  validity  -  just  as  if  the  checks  became  part  of  the  orig¬ 
inal  dHOL  logic.  Owing  to  the  expressive  VeriML  type  system,  this  is  done  without  needing  to  extend 
the  logic  at  all.  This  amounts  to  user-extensible  static  checking  within  tactics,  which  we  cover  in  more  detail 
in  Section  7.2. 

The  support  of  user-extensible  static  checking  enables  us  to  layer  checking  functions,  so  as  to  simplify 
their  implementation,  as  shown  in  Figure  7.2.  This  corresponds  to  mathematical  practice:  when  working 
on  proofs  of  a  domain  such  as  arithmetic,  we  omit  trivial  details  such  as  equality  rewriting  steps.  Once  we 
have  a  fair  amount  of  intuition  about  arithmetic,  we  can  move  to  further  domains  such  as  linear  algebra 
-  where  arithmetic  steps  themselves  become  trivial  and  are  omitted;  and  so  on.  Similarly,  by  layering 
static  checking  procedures  for  increasingly  more  complicated  domains,  we  can  progressively  omit  more 
trivial  details  from  the  proofs  we  use  in  VeriML.  This  is  true  whether  we  are  interested  in  the  proofs 
themselves,  or  when  the  proofs  are  parts  of  tactics,  used  to  provide  automation  for  further  domains.  For 
example,  once  we  have  programmed  a  conversion  rule  that  supports  congruence  closure,  programming  a 
conversion  rule  that  supports  /3-reduction  is  simplified.  The  reason  is  that  the  proofs  contained  within 
the  /3-conversion  rule  do  not  have  to  mention  the  congruence  proof  steps,  just  as  we  could  skip  details  in 
evenOrOdd  above.  Similarly,  implementing  an  arithmetic  conversion  rule  benefits  from  the  existence  of 
congruence  closure  and  /3-conversion. 

Our  approach  to  user-extensible  static  checking  for  proofs  and  tactics  can  in  fact  be  viewed  as  a  more 
general  feature  of  VeriML:  the  ability  to  support  extensible  type  checking.  Functional  languages  such  as 
ML  and  Haskell  allow  users  to  define  their  own  algebraic  datatypes.  Dependently  typed  languages,  such 
as  versions  of  Haskell  with  GADTs  [Peyton  Jones  et  ah,  2006]  and  Agda  [Norell,  2007],  allow  users  to 
define  and  enforce  their  own  invariants  on  those  datatypes,  through  dependent  types.  Yet,  since  the  type 
checking  procedure  of  such  languages  is  fixed,  these  extra  invariants  cannot  always  be  checked  statically. 
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VeriML  allows  us  to  program  the  automated  procedures  to  prove  such  invariants  within  the  same  language 
and  evaluate  them  statically  through  the  staging  mechanism.  In  this  way,  type  checking  becomes  extensi¬ 
ble  by  user-defined  properties  and  user-defined  checking  procedures,  while  type  safety  is  maintained.  The 
details  of  this  idea  are  the  subject  of  Section  7.3. 

7.1  User-extensible  static  checking  for  proofs 

7.1.1  The  extensible  conversion  rule 

Issues  with  the  explicit  equality  approach.  In  Section  3.2  we  presented  various  alternatives  to  handling 
equality  within  the  dHOL  logic.  We  chose  the  explicit  equality  approach,  where  every  equality  step  is 
explicitly  witnessed  inside  proofs.  As  we  discussed,  this  leads  to  the  simplest  possible  type-checker  for 
the  logic.  Yet  equality  steps  are  so  ubiquitous  inside  proofs  that  proof  objects  soon  become  prohibitively 
large.  One  such  example  is  proving  that  ( succ  x)  +  y  =  succ  ( x  +y).  Assuming  the  following  constants  in 
the  signature  S  concerning  natural  numbers,  where  elimNat  represents  primitive  recursion  over  them: 

Nat  :  Type 

zero  :  Nat 

succ  :  Nat  —*■  Nat 

elimNat^  :  1C  — >  (Nat  — *■  JC  —*■  1C)  — ►  Nat  — *  1C 

elimNatZero  :  V/^/j ,  elimNat K  f7  fs  zero  =  fz 

elimNatSucc  :  V fzfsp,elimNatlc  fz  fs  ( succ  p)=  fs  p  ( elimNat K  fz  fs  p) 
we  can  define  natural  number  addition  as: 

plus  =  Xa  :  Nat.Xb  :  Nat.elimNatNat  b  (Xp.Xr.succ  r)  a 
To  prove  the  desired  proposition,  we  need  to  go  through  the  following  steps: 
plus  (succ  x)  y  = 

—  (Xa:  Nat.Xb  :  Nat. elimNat  b  (Xp.Xr.succ  r)  a)  (succ  x)y 

(by  definition  of  plus) 

=  (Xb  :  Nat.elimNat  b  (Xp.Xr.succ  r)  (succ  %))  y 

(by  EqBeta) 

=  elimNat  y  (Xp.Xr.succ  r)  (succ  x) 

(by  EqBeta) 

=  (Xp.Xr.succ  r)  x  (elimNat  y  (Xp.Xr.succ  r)  x) 

(by  elimNatSucc) 

=  succ  (elimNat  y  (Xp.Xr.succ  r)  x) 

(by  EqBeta,  twice) 

=  succ  (plus  x  y) 

(by  EqBeta  and  EqSymm,  twice) 

The  resulting  proof  object  explicitly  mentions  this  steps,  as  well  as  uses  of  equality  transitivity  in  order 
to  combine  the  steps  together.  Generating  and  checking  such  objects  with  such  painstaking  level  of  detail 
about  equality  soon  becomes  a  bottleneck.  For  example,  imagine  the  size  of  a  proof  object  proving  that 
100000  +  100000  =  200000:  we  would  need  at  least  100000  applications  of  logical  rules  such  as  EqBeta 
and  elimNatSucc  in  order  to  prove  a  proposition  which  otherwise  follows  trivially  by  computation. 
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Extensions  to  typing  (stratified  version) 


$  hc  7i :  P  P  =/jN  P' 

- 7 - Conversion 

$  bc  71 :  P' 


Extensions  to  typing  (PTS  version) 


b c  t :  t'  $  bc  t :  Prop  t'  =oN  t" 

- 77 - - - Conversion 

$  bc  t :  t 


(Ax  :  JC.t)  t'  — t  [ t7/ x] 

elimNatfc  tz  ts  zero  — » tz 

elimNatK  tz  ts  (succ  t)  — ts  t  ( elimNat K  tz  ts  t) 


The  compatible  (t  =  t'  =>  t"[t/x]  =  t”(t' /x\),  reflexive,  symmetric  and  transitive 
closure  of  t  — t' 

Figure  7.3:  The  logic  /HOLc  :  Adding  the  conversion  rule  to  the  dHOL  logic 
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Introducing  the  conversion  rule.  In  order  to  solve  this  problem,  various  logics  introduce  a  notion 
of  terms  that  are  definitionally  equal :  that  is,  they  are  indistinguishable  with  respect  to  the  logic.  For 
example,  we  can  say  that  terms  that  are  equivalent  based  on  computation  alone  such  as  100000  +  100000 
and  200000  or  ( succ  x)+y  and  succ  (x+y)  correspond  to  the  same  term.  In  this  way,  the  rewriting  steps  to 
go  from  one  to  the  other  do  not  need  to  be  explicitly  witnessed  in  a  proof  object  and  a  simple  application 
of  reflexivity  is  enough  to  prove  their  equality: 

F  (re/7  ((succ  x)+y)) :  ((succ  x)  +  y  =  succ  (x  +y)) 

This  typing  derivation  might  be  surprising  at  first:  we  might  expect  the  type  of  this  proof  object  to  be 
((succ  x)  +  y )  =  ((succ  x)  +  y).  Indeed,  this  is  a  valid  type  for  the  proof  object.  But  since  ((succ  x)  +  y)  is 
indistinguishable  from  succ  (x  +y),  the  type  we  gave  above  for  this  proof  object  is  just  as  valid. 

In  order  to  include  this  notion  of  definitional  equality,  we  introduce  a  conversion  rule  in  the  xHOL 
logic,  with  details  shown  in  Figure  7.3.  We  denote  definitional  equality  as  =  and  include  /3-reduction 
and  natural  number  primitive  recursion  as  part  of  it.  The  conversion  rule  is  practically  what  makes 
definitionally  equal  terms  indistinguishable,  allowing  to  view  a  proof  object  for  a  proposition  P  as  a  proof 
object  for  any  definitionally  equal  proposition  P' .  In  order  to  differentiate  between  the  notion  of  xHOL 
with  explicit  equality  that  we  have  considered  so  far,  we  refer  to  this  version  with  the  conversion  rule  as 
/HOLc  and  its  typing  judgement  as  T;  T  bf  t  :  t1;  whereas  the  explicit  equality  version  is  denoted  as 
kHOL£. 

Including  the  conversion  rule  in  kHOL  means  that  when  we  prove  the  metatheory  of  the  logic,  we 
need  to  prove  that  the  conversion  rule  does  not  introduce  any  unsoundness  to  the  logic.  This  proof 
complicates  the  metatheory  of  the  logic  significantly.  Furthermore,  the  trusted  base  of  a  system  relying 
on  this  logic  becomes  bigger.  The  reason  is  that  the  implementation  of  the  logic  type  checker  now  needs  to 
include  the  implementation  of  the  conversion  rule.  This  implementation  can  be  rather  large,  especially  if 
we  want  the  conversion  rule  to  be  efficient.  The  implementation  essentially  consists  of  a  partial  evaluator 
for  the  functional  language  defined  through  /3-reduction  and  natural  number  elimination.  This  can  be 
rather  complicated,  especially  as  evaluation  strategies  such  as  compilation  to  bytecode  have  been  suggested 
[Gregoire,  2003],  Furthermore,  it  is  desirable  to  support  even  more  sophisticated  definitional  equality  as 
part  ofthe  conversion  rule,  as  evidenced  in  projects  such  as  Blanqui  et  al.  [1999],Strub  [2010]  andBlanqui 
et  al.  [2010],  For  example,  by  including  congruence  closure  in  the  conversion  rule,  proof  steps  that 
perform  rewriting  based  on  hypotheses  can  be  omitted:  if  we  know  that  x  =  y  and  y  =  z,  then  proving 
f  x=  f  z  becomes  trivial.  The  size  of  the  resulting  proof  objects  is  further  reduced.  Of  course,  extending 
definitional  equality  also  complicates  the  metatheory  further  and  enlarges  the  trusted  base.  Last,  user 
extensions  to  definitional  equality  are  impossible:  any  new  extension  requires  a  new  metatheoretic  result 
in  order  to  make  sure  that  it  does  not  violate  logical  soundness. 

The  conversion  rule  in  VeriML.  We  will  now  see  how  VeriML  makes  it  possible  to  reconcile  the 
explicit  equality  based  approach  with  the  conversion  rule:  we  will  gain  the  conversion  rule  back,  albeit 
it  will  remain  completely  outside  the  logic.  Therefore  we  will  be  free  to  extend  it,  all  the  while  without 
risking  introducing  unsoundness  in  the  logic,  since  the  logic  remains  fixed  (kHOL£  as  presented  above). 

The  crucial  step  is  to  recognize  that  the  conversion  rule  essentially  consists  of  a  trusted  tactic  that  is 
hardcoded  within  the  logic  type  checker.  This  tactic  checks  whether  two  terms  are  definitionally  equal  or 
not;  if  it  claims  that  they  are,  we  trust  that  they  are  indeed  so,  and  no  proof  object  is  produced.  This  is 
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where  the  space  gains  come  from.  We  can  thus  view  the  definitional  equality  checker  as  a  trusted  function 
of  type: 

defEqual  :  (P  :  Prop)  —*■  ( P ' :  Prop )  — ►  bool 

and  the  conversion  rule  as  follows: 

&\~cn:P  defEqual  P  P' — true 

- — - Conversion 

<&\~c  TZ  '.P' 

where  — »■*  stands  for  the  operational  semantics  of  ML  -  the  meta-language  where  the  type  checker  for 
dHOL  is  implemented. 

This  key  insight  leads  to  our  alternative  treatment  of  the  conversion  rule  in  VeriML.  First,  instead 
of  hardcoding  the  trusted  definitional  equality  checking  tactic  inside  the  logic  type  checker,  we  program 
a  type-safe  definitional  equality  tactic,  utilizing  the  features  of  VeriML.  Based  on  typing  alone,  we  require 
that  this  function  returns  a  valid  proof  object  of  the  claimed  equivalences: 

defEqual  :  (cf> :  ctx,  P  :  Prop,  P1 :  Prop)  —*  option  (P  =  P;) 

Second,  we  evaluate  this  tactic  under  proof  erasure  semantics.  This  means  that  no  proof  object  for  P  =  P' 
is  produced,  leading  to  the  same  space  gains  as  the  original  conversion  rule.  In  fact,  under  this  semantics, 
the  type  option  (P  =  Pfi  is  isomorphic  to  bool  -  so  the  correspondence  with  the  original  conversion 
rule  is  direct.  Third,  we  use  the  staging  construct  in  order  to  check  conversion  statically.  In  this  way,  we 
will  know  whether  the  conversion  checks  are  successful  as  soon  as  possible,  after  stage-one  evaluation. 
The  main  reason  why  this  is  important  will  be  mostly  evident  in  the  following  section.  Informally,  the 
conversion  rule  now  becomes: 

^  h£  7T  :  P  {{defEqual  <f>  P  P'}er;isc}st;itk  -^yeriML  Some  ( admit ) 

$  \~E  Ti :  P1 

Through  this  treatment,  the  choice  of  what  definitional  equality  corresponds  to  can  be  decided  at  will  by 
the  VeriML  programmer,  rather  than  being  fixed  at  the  time  of  the  definition  of  dHOL. 

As  it  stands  the  rule  above  mixes  typing  for  /HOL  terms  with  the  operational  semantics  of  a  VeriML 
expression.  Since  typing  for  VeriML  expressions  depends  on  /HOL  typing,  adding  a  dependence  on 
the  VeriML  operational  semantics  would  severely  complicate  the  definition  of  the  VeriML  language.  We 
would  not  be  able  to  use  the  standard  techniques  of  proving  type  safety  in  the  style  of  Chapter  6.  We 
resolve  this  by  leaving  the  conversion  rule  outside  the  logical  core.  Instead  of  redefining  typing  for  dHOL 
proof  objects  we  will  define  a  notion  of  proof  object  expressions,  denoted  as  en.  These  are  normal  VeriML 
expressions  which  statically  evaluate  to  a  proof  object.  The  only  computational  part  they  contain  are  calls 
to  the  definitional  equality  tactic.  Thus  the  combination  of  VeriML  typing  and  VeriML  static  evaluation 
for  proof  object  expressions  exactly  corresponds  to  dHOLc  typing  for  proof  objects: 

$  hc  7T  :  P  <=>  •;  •;  L  I-  en  :  (P)  A  (  p ,  en  )  — V  (p,  (k  ')) 

We  will  show  that  we  can  convert  any  dHOLc  proof  object  n  into  an  equivalent  proof  object  expression 
through  a  type-directed  translation:  [[$  bc  n  :  PJ  =  en.  Through  proof-erasure  the  calls  to  the  defini¬ 
tional  equality  tactic  will  not  produce  proof  objects  at  runtime,  yielding  the  space  savings  inherrent  in  the 
/HOLf  approach.  Furthermore,  since  the  use  of  proof  erasure  semantics  is  entirely  optional  in  VeriML, 
we  can  also  prove  that  a  full  proof  object  in  the  original  dHOL£  logic  can  be  produced: 
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$\-cn:P  l$\-cn:PJ=e  n  — ►*  (  p  ,  {  n  )  ) 

$  b£  n  :  P 

This  proof  object  only  requires  the  original  type  checker  for  dHOL£  without  any  conversion-related 
extensions,  as  all  conversion  steps  are  explicitly  witnessed. 

Formal  details.  We  are  now  ready  to  present  our  approach  formally.  We  give  the  implementation 
of  the  definitional  equality  checker  in  VeriML  in  Code  Listings  7. 1  and  7.2.  We  support  the  notion 
of  definitional  equality  presented  above:  the  compatible  closure  over  /3-reduction  and  natural  number 
elimination  reduction.  As  per  standard  practice,  equality  checking  is  split  into  two  functions:  one  which 
reduces  a  term  to  weak-head  normal  form  (rewriteBetaNat  in  Code  Listing  7.1)  and  the  actual  checking 
function  defEqual  which  compares  two  terms  structurally  after  reduction.  We  also  define  aversion  of  the 
tactic  that  raises  an  error  instead  of  returning  an  option  type  if  we  fail  to  prove  the  terms  equal,  which  we 
call  reqEqual.  For  presentation  reasons  we  omit  the  proof  objects  contained  within  the  tactics.  We  instead 
name  the  respective  proof  obligations  within  the  tactics  as  G-  and  give  their  type.  Most  obligations  are 
easy  to  fill  in  based  on  our  presentation  of  dHOL£  in  Section  3.2  and  can  be  found  in  our  prototype 
implementation  of  VeriML. 

The  code  of  the  defEqual  tactic  is  entirely  similar  to  the  code  one  would  write  for  the  definitional 
equality  checking  routine  inside  the  dHOLc  logic  type  checker,  save  for  the  extra  types  and  proof  objects. 

It  therefore  follows  trivially  that  everything  that  holds  for  the  standard  implementation  of  the  conversion 
check  also  holds  for  this  code:  e.g.  it  corresponds  exactly  to  the  relation  as  defined  in  the  logic;  it 
is  bound  to  terminate  because  of  the  strong  normalization  theorem  for  this  relation;  and  its  proof-erased 
version  is  at  least  as  trustworthy  as  the  standard  implementation.  Formally,  we  write: 

Lemma  7.1.1 

$hl:T  t  t'  $  b  t  :T  reqEqual  $T  t  t'  — *■*  error 

1. - - - - -  2. - - - 

reqEqual  $  T  t  t  — **  (n)  $\~  n  :  t  =  t'  t  t 

Proof.  Through  standard  techniques  show  that  =  is  equivalent  to  structural  equality  modulo  rewrit¬ 
ing  to  /3N-weak  head-normal  form.  Then,  by  showing  that  the  combination  of  defEqual  and  rewriteBetaNat 
accurately  implement  the  latter  relation.  □ 

With  this  implementation  of  definitional  equality  in  VeriML,  we  are  now  ready  to  translate  dHOL£ 
proof  objects  into  VeriML  expressions.  Essentially,  we  will  replace  the  implicit  definitional  equality 
checks  used  in  the  conversion  rule  within  the  proof  objects  with  explicit  calls  to  the  reqEqual  tactic. 
We  define  a  type-directed  translation  function  in  Figure  7.4  that  does  exactly  that.  The  auxiliary  function 
[[$  bc  nc  :  PJ  forms  the  main  part  of  the  translation.  It  yields  an  equivalent  dHOL£  proof  object  nE, 
which  is  mostly  identical  to  the  original  dHOLc  proof  object,  save  for  uses  of  the  conversion  rule.  A 
use  of  the  conversion  rule  for  terms  t  and  t'  is  replaced  with  an  explicit  proof  object  that  has  a  place¬ 
holder  Gi  for  the  proof  of  t  =  t' .  The  same  auxiliary  function  also  yields  a  map  from  the  placeholders 
Gt  into  triplets  (<3>,  t,  t')  that  record  the  relevant  information  of  each  use  of  the  conversion  rule  2.  The 
main  translation  function  [[$  bc  nc  :  PJ  then  combines  these  two  parts  into  a  valid  VeriML  expression, 
calling  the  reqEqual  tactic  in  order  to  fill  in  the  G -t  placeholders  based  on  the  recorded  information. 

2.  We  assume  that  the  names  and  uses  of  the  Gt  are  a-converted  accordingly  when  joining  lists  together. 
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rewriteBetaNatStep  :  (<f> :  ctx,  T  :  Type,  t  :  T)  —*■  (t' :  T)  x  (t  =  t ') 

rewriteBetaNatStep  <f>  T  t  = 
holmatch  t  with 

T)  (t2  :  T') 

2writeBetaNat  &  (T1  — »•  T)  t,  in 


II 

r-t- 

) 

r-+ 

II 

t' 

holmatch  t'y  with 

Ax  :  T'.tf  /  tf/lid^,  t2],  G,  ) 

I  l'\  ^  \  *i'  G2  ) 

in 

( o3 ) 

|  elimNatj  fzfsn  > 

let  (  /f3  )  =  rewriteBetaNat  </>  Nat  n  in 

let  ^  t' ,  H4  :  elimNatj-  fzfsn'  —  t'  ^  = 
holmatch  n!  with 
zero  (/z,  G4) 

|  s^cc  n'  i->  ( f$  ri  {elimNatj  fx  fs  n'),  G5  ) 

|  w/  i->  (  elimNatj  fz  fs  n! ,  G6  ) 

in 

(  g7  ) 

1 1  ^  (  G  G8  ) 

rewriteBetaNat  :  {<f> :  ctx,  T  :  Type,  t :  T)  —*■  (V  :  T)  x  {t  =  t') 
rewriteBetaNat  </>  T  t  — 

let  (^tf,  H5:  t  —  t'  ^  =  rewriteBetaNatStep  cj>T  t  in 
holmatch  t'  with 

t  >-+  ( t,  G9  ) 

|  t'  >-*•  let  (  t",  He)  =  rewriteBetaNat  <f>T  t'  in  (  t",  G10  ) 


Code  Listing  7.1:  Implementation  of  the  definitional  equality  checker  in  VeriML  (1/2) 
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defEqual  :  (<f> : 

defEqual  (j)T  tx 
/ 

let  i 

\  V  ■ 

let  i 

!  t'  fr  . 
iy  1 2>  ■ 

do  ( 

1  H:  t(  — 
\  1 

¥  :  V 

h  =  h 


=  rewriteBetaNat  <f>  T  t1 


in 


in 


do  <  Ha  '■  ta  =  h 


holmatch  t  ,  t'  with 
->• 

—  defEqual  <j>  T  ta  tc 
Hb:  h  =  td  )  defEqual  <j>  T  tb  td 
return  (  G,  :  ta  th  =  tc  td  } 

I  ((ta:T')  =  tb),  {tc  =  td)~ 


H  ■ 
return 


ta  =  tc 

1  <—  defEqual  cf>  T' 

r-t- 

<5- 

II 

^  <—  defEqual  </>  T 

(G2:  ( 

^3 

II 

¥ 

-Si 

II 

L3 

I  (*,  -»•  h\  ¥  -*■  td) 
do  ta  =  tc 

Hu  ’■  tu  =  tj 


defEqual  <f>  Prop  ta  tc 
-  defEqual  </>  Prop  tb  td 


return  ^  G3 :  (ta^  tb)  =  (tc  -+  td)  } 

|  (Vx  :  T ,  ta),  <yx:T',th)~ 
do  (Ha:  ta  =  tb  )  defEqual  ((f),  x  :  T')Prop  ta  t 
return  ^  G4  :  (Vx  :  T ,  ta)  =  (Vx  :  T ,  tb)  ^ 

|  (Ax  :  T'.(ta  :  T'%  (Ax  :  T'.tb)  ~ 
do  (  Ha  :  ta  =  h  )  defEqual  (</>,  x  :  T')  T"  ta  tb 


return 


(G5:  (Ax:V.ta)  =  (Ax:T'.tb)  ) 


ta  >  G 


do  return  (  G6  : 


-*■  None 


in  return  (  G  :  £t  =  t2 


reqEqual  :  (<f> :  ctx,  T  :  Type,  t1  :  T,  t2:T)^>  (tt  =  t2) 
reqEqual  </>  T  t{  t2  =  match  defEqual  <f>T  txt2  with 

Some  ^  H  :  tx  =  t2 
\  None 


(H) 

error 


Code  Listing  7.2:  Implementation  of  the  definitional  equality  checker  in 
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VeriML  (2/2) 


p  i"c  nc :  pr = ( nE  v ) 


[$,  %  :  P  hc  nc  :  P'J  =(nE\l) 


►Intro 


[$  hc  Xx  :  P.nc  :  P  P'J '  =  (  Xx  :  P.tt£  |  /  } 

[$hc4=p'^p],=  (g'|/‘)  [i>hc4:P'],=  (4i;2) 

[$|-c"c,rc:/’],=  {"ilr£  M'w'2) 

[[$,  %:/d-C7TC:P]]/=(7r£|/} 

- - - VlNTRO 

p  hc  /!%  :  PZ.Kq  :  Vx  :  /C.P]]  =  (Xx  :  JC.nE  \  l ) 


►Elim 


l<$>\-cnc:Vx:lC.Pf  =  (nE\l) 
l<f>\-cncd  :P[d/x]f  =  {nEd\l) 


VElim 


- - - VAR 

p  x  :  PJ  =  (  x  |  0  } 


E$hc7rc:Pl=(7r£|/)  P=^P'  Gnjl 

P  l"C  nc  :  P1  =  (  COnV  71 E  Gn  I  /  W  iGn  *+  P>  P’  P0]  ) 


Conversion 


P  P  nC  :  P1  =  e7T 


phC7rc:Pr=(7r£l/)  |/|  =  »  /  =  G,--»($,-,  PpP-) 

p  hc  nc  :  PJ  =  (letstatic  (  Gj }  =  [J^reqEqual  Prop  P1  PjJ  in 


letstatic  (Gn)  =  [J^reqEqual  Prop  Pn  P'J£  in 

<PP£» 


Figure  7.4:  Conversion  of  aHOLc  proof  objects  into  VeriML  proof  object  expressions 
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While  this  translation  explicitly  records  the  information  for  every  use  of  conversion  -  that  is,  the 
triplet  (T,  t,  t'),  a  very  important  point  we  need  to  make  is  that  VeriML  type  information  can  be  used  to 
infer  this  information.  Therefore,  an  alternate  translation  could  produce  VeriML  proof  object  expressions 
of  the  form: 

letstatic  Gt  =  [[reqEqual _ J£  in 

letstatic  Gn  =  [[reqEqual _ J£  in 

(nE) 

This  evidences  a  clear  benefit  of  recording  logic-related  information  in  types:  based  on  typing  alone,  we 
can  infer  normal  arguments  to  functions,  even  when  these  have  an  actual  run-time  role,  such  as  t  and  t' . 
The  function  req Equal  pattern  matches  on  these  objects,  yet  their  values  can  be  inferred  automatically 
by  the  type  system  based  on  their  usage  in  a  larger  expression.  This  benefit  can  be  pushed  even  further 
to  eliminate  the  need  to  record  the  uses  of  the  conversion  rule,  allowing  the  user  to  write  proof  object 
expressions  that  look  identical  to  dHOLc  proof  objects.  Yet,  as  we  will  see  shortly,  proof  object  expres¬ 
sions  are  free  to  use  an  arbitrary  conversion  rule  instead  of  the  fixed  conversion  rule  in  /HOLf;;  thus, 
by  extending  the  conversion  rule  appropriately,  we  can  get  small  proof  object  expressions  even  in  cases 
where  the  corresponding  dHOLc  proof  object  would  be  prohibitively  large. 

We  will  not  give  the  full  details  of  how  to  hide  uses  of  the  conversion  rule  in  proof  object  expressions. 
Briefly  we  will  say  that  this  goes  through  an  algorithmic  typing  formulation  for  /HOLc  proof  objects: 
instead  of  having  an  explicit  conversion  rule,  conversion  checks  are  interspersed  in  the  typing  rules  for 
the  other  proof  object  constructors.  For  example,  implication  elimination  is  now  typed  as  follows: 

$  bc  n  :  P  -+  P"  $  bc  7Z  :  P'  P  EEgN  P' 

$  bc  n  n  :  P" 

Having  such  a  formulation  at  hand,  we  implement  each  such  typing  rule  as  an  always-terminating  VeriML 
function  with  an  appropriate  type.  Conversion  checks  are  replaced  with  a  requirement  for  proof  evidence 
of  the  equivalence.  For  example: 

implElim  :  (<f> :  ctx,  P,P',P"  :  Prop,  HX:P  P1,  H2  :P',  H3:P  =  P1)  — ►  (P") 

Then,  the  translation  from  /HOLf  proof  objects  into  proof  object  expressions  replaces  every  typing  rule 
with  the  VeriML  tactic  that  implements  it.  Type  inference  is  used  to  omit  all  but  the  necessary  arguments 
to  these  tactics;  and  static,  proof-erased  calls  to  reqEqual  are  used  to  solve  the  equivalence  goals.  Thus 
through  appropriate  syntactic  sugar  to  hide  the  inferred  arguments,  the  calls  to  the  corresponding  VeriML 
tactics  look  identical  to  the  original  proof  object. 

Correspondence  with  original  proof  object.  We  use  the  term  proof  object  expressions  to  refer  to  the 
VeriML  expressions  resulting  from  this  translation  and  denote  them  as  en.  We  will  now  elucidate  the 
correspondence  between  such  proof  object  expressions  and  the  original  dHOLc  proof  object.  To  do  that, 
it  is  fruitful  to  view  the  proof  object  expressions  as  a  proof  certificate,  sent  to  a  third  party.  The  steps 
required  to  check  whether  it  constitutes  a  valid  proof  are  the  following.  First,  the  whole  expression  is 
checked  using  the  VeriML  type  checker;  this  includes  checking  the  included  dHOL£  proof  object  nE 
through  the  dHOL£  type  checker.  Then,  the  calls  to  the  reqEqual  function  are  evaluated  during  stage 
one,  using  proof  erasure  semantics  and  thus  do  not  produce  additional  proof  objects.  We  expect  such  calls 
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to  req Equal  to  be  successful,  just  as  we  expect  the  conversion  rule  to  be  applicable  in  the  original  /lHOLc 
proof  object  when  it  is  used.  Last,  stage-two  evaluation  is  performed,  but  the  proof  object  expression 
has  already  been  reduced  to  a  value  after  the  first  evaluation  stage.  Thus  checking  the  validity  of  the 
proof  expression  is  entirely  equivalent  to  the  behavior  of  type-checking  the  /HOLf  proof  object,  save 
for  pushing  all  conversion  checks  towards  the  end.  Furthermore,  the  size  of  the  proof  object  expression 
en  is  comparable  to  the  original  nc  proof  object;  the  same  is  true  for  the  resulting  nE  proof  object  when 
proof  erasure  semantics  are  used  for  the  calls  to  reqEqual.  Of  course,  use  of  the  proof  erasure  semantics 
is  entirely  optional.  If  we  avoid  using  them  (e.g.  in  cases  where  the  absolute  minimum  trusted  base  is 
required),  the  resulting  nE  proof  object  will  be  exponentially  larger  due  to  the  full  definitional  equality 
proofs. 

Formally,  we  have  the  following  lemma,  assuming  no  proof  erasure  semantics  are  used  for  VeriML 
evaluation. 

Lemma  7.1.2  (\HOLc  proof  object  -  VeriML  proof  object  expression  equivalence) 

_ $  l~ cnC:P  D>  hC  nC  :  =  en _ 

•hert:([$]P)  — ♦*  ( [$]  nE  )  ^\~EnE:P 

Extending  conversion  at  will.  In  our  treatment  of  the  conversion  rule  we  have  so  far  focused  on  re¬ 
gaining  the  conversion  rule  with  as  the  definitional  equality  in  our  framework.  Still,  there  is  nothing 
confining  us  to  supporting  this  notion  of  definitional  equality  only.  As  long  as  we  can  program  an  equiva¬ 
lence  checker  in  VeriML  that  has  the  right  type,  it  can  safely  be  made  part  of  the  definitional  equality  used 
by  our  notion  of  the  conversion  rule.  That  is,  any  equivalence  relation  R  can  be  viewed  as  the  definitional 
equality  =R,  provided  that  a  defEqual^  tactic  that  implements  it  can  be  written  in  VeriML,  with  the  type: 

defEqual^  :  (<f> :  ctx,  T  :  Type ,  t :  T,  t'  :T)—+  option  (t  =  t') 

For  example,  we  have  written  an  eufEqual  function,  which  checks  terms  for  equivalence  based  on  the 
equality  with  uninterpreted  functions  decision  procedure  -  also  referred  to  as  congruence.  This  equiva¬ 
lence  checking  tactic  isolates  hypotheses  of  the  form  t]  =  t2  from  the  current  context;  then,  it  constructs  a 
union-find  data  structure  in  order  to  form  equivalence  classes  of  terms.  Based  on  this  structure,  and  using 
code  similar  to  defEqual  (recursive  calls  on  subterms),  we  can  decide  whether  two  terms  are  equal  up  to 
simple  uses  of  the  equality  hypotheses  at  hand.  We  have  combined  this  tactic  with  the  original  defEqual 
tactic,  making  the  implicit  equivalence  supported  similar  to  the  one  in  the  Calculus  of  Congruent  Con¬ 
structions  [Blanqui  et  ah,  2005],  This  demonstrates  the  flexibility  of  this  approach:  equivalence  checking 
is  extended  with  a  sophisticated  decision  procedure,  which  is  programmed  using  its  original,  imperative 
formulation.  We  have  extended  defEqual  further  in  order  to  support  rewriting  based  on  arithmetic  facts, 
so  that  simple  arithmetic  simplifications  are  taken  into  account  as  part  of  the  conversion  rule. 

In  our  implementation,  we  have  programmed  the  equality  checking  procedure  defEqual  in  an  exten¬ 
sible  manner,  so  that  we  can  globally  register  further  extensions.  We  present  details  of  this  in  Chap¬ 
ter  9.  We  can  thus  view  defEqual  as  being  composed  from  a  number  of  equality  checkers  defEqual^,  •  •  • , 
defEqual^  ,  corresponding  to  the  definitional  equality  relation  =riU...uk  •  We  will  refer  to  this  relation  as 
=R- 

We  would  like  to  stress  that  by  keeping  the  conversion  rule  outside  the  logic,  the  user  extensions 
cannot  jeopardize  the  soundness  of  the  logic.  This  choice  also  allows  for  adding  undecidable  equivalences 
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to  the  conversion  rule  (e.g.  functional  extensionality)  or  potentially  non-terminating  decision  procedures. 
Soundness  is  guaranteed  thanks  to  the  VeriML  type  system,  by  requiring  that  extensions  return  a  proof  of 
the  claimed  equivalences.  Through  type  safety  we  know  that  such  a  proof  exists,  even  if  it  is  not  produced 
at  runtime. 

We  actually  make  use  of  non-terminating  extensions  to  the  conversion  rule  in  our  developments.  For 
example,  before  implementing  the  eufEqual  tactic  for  deciding  equivalence  based  on  equality  hypotheses, 
we  implement  a  naive  version  of  the  same  tactic,  that  blindly  rewrites  terms  based  on  equality  hypotheses 
-  that  is,  given  a  hypothesis  a  =  b  and  two  terms  t  and  t'  to  test  for  equivalence,  it  rewrites  all  occurrences 
of  a  to  b  inside  t  and  t1.  While  this  strategy  would  lead  to  non-termination  in  the  general  case,  it  sim¬ 
plifies  implementing  eufEqual  significantly,  as  many  proof  obligations  within  that  tactic  can  be  handled 
automatically  through  the  naive  version.  After  eufEqual  is  implemented,  the  naive  version  does  not  get 
used.  Still,  this  usage  scenario  demonstrates  that  associating  decidability  of  equivalence  checking  with  the 
soundness  of  the  conversion  rule  is  solely  an  artifact  of  the  traditional  way  to  integrate  the  conversion 
rule  within  the  internals  of  the  logic. 

7.1.2  Proof  object  expressions  as  certificates 

In  terms  of  size  and  checking  behavior,  a  proof  object  expression  en  that  makes  calls  to  an  appropriately 
extended  defEqual  procedure  corresponds  closely  to  proof  objects  with  a  version  of  dHOLc  with  =R  as 
the  definitional  equality  used  in  the  conversion  rule.  These  proof  object  expressions  can  be  utilized  as 
an  alternative  proof  certificate  format,  to  be  sent  to  a  third  party.  Their  main  benefit  over  proof  objects 
is  that  they  allow  the  receiving  third  party  to  decide  on  the  tradeoff  between  the  trusted  base  and  the 
cost  of  validity  checking.  This  is  due  to  the  receiver  having  a  number  of  choices  regarding  the  evaluation 
of  each  defEqual^  implementing  the  sub-relations  =R  of  =R.  First,  the  receiver  can  use  proof  erasure 
for  evaluation  as  suggested  above.  In  this  case,  the  proof-erased  version  of  defEqual^  becomes  part  of  the 
trusted  base  -  though  the  fact  that  it  has  been  verified  through  the  VeriML  type  system  gives  a  much  better 
assurance  that  the  function  can  indeed  be  trusted.  Another  choice  would  be  to  use  non-erasure  semantics 
and  have  the  function  return  an  actual  proof  object.  This  is  then  checked  using  the  original  dHOL£  type 
checker.  In  that  case,  the  VeriML  type  system  does  not  need  to  become  part  of  the  trusted  base  of  the 
system.  Last,  the  ‘safest  possible’  choice  would  be  to  avoid  doing  any  evaluation  of  the  function,  and  ask 
the  proof  certificate  provider  to  do  the  evaluation  of  defEqual^  themselves.  In  that  case,  no  evaluation 
of  its  code  would  need  to  happen  at  the  proof  certificate  receiver’s  side.  This  mitigates  any  concerns  one 
might  have  for  code  execution  as  part  of  proof  validity  checking,  and  guarantees  that  the  small  dHOL£ 
type  checker  is  the  trusted  base  in  its  entirety. 

The  receiver  can  decide  on  the  above  choices  separately  for  each  defEqual^  -  e.g.  use  proof  erasure  for 
rewriteBetaNat  but  not  for  eufEqual,  leading  to  a  trusted  base  identical  to  the  dHOLc  case.  This  means 
that  the  choice  of  what  the  conversion  rule  is  rests  with  the  proof  certificate  receiver  and  not  with  the  designer 
of  the  logic.  Thus  the  proof  certificate  receiver  can  choose  the  level  of  trust  they  require  at  will,  while 
taking  into  account  the  space  and  time  resources  they  want  to  spend  on  validation.  Still,  the  producer 
of  the  proof  certificate  has  the  option  of  further  extensions  to  the  conversion  rule.  Thus  proof  object 
expressions  constitute  an  extensible  proof  certificate  format  -that  is,  a  certificate  format  with  an  extensible 
checking  procedure-  that  still  allows  for  the  actual  size  of  the  checking  procedure,  or  the  trusted  base,  to 
be  decided  by  the  checking  party. 
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Disambiguating  between  notions  of  proof.  So  far  we  have  introduced  a  number  of  different  notions 
of  proof:  proof  objects  in  /,HOLc  and  dHOL£;  proof  object  expressions  and  proof  expressions;  we  have 
also  mentioned  proof  scripts  in  traditional  proof  assistants.  Let  us  briefly  try  to  contrast  and  disambiguate 
between  these  notions. 

As  we  have  said,  proof  objects  in  dHOL£  are  a  kind  of  proof  certificate  where  every  single  proof 
step  is  recorded  in  full  detail;  therefore,  the  size  of  the  trusted  base  required  for  checking  them  is  the 
absolute  minimum  of  the  frameworks  we  consider.  Yet  their  size  is  often  prohibitively  large,  rendering 
their  transfer  to  a  third  party  and  their  validation  impractical.  Proof  object  expressions  in  VeriML,  as 
generated  by  the  translation  offered  in  this  chapter,  can  be  seen  as  proof  objects  with  some  holes  that  are 
filled  in  computationally.  That  is,  some  simple  yet  tedious  proof  steps  are  replaced  with  calls  to  verified 
VeriML  proof-producing  functions.  The  fact  that  these  functions  are  verified  is  a  consequence  of  requiring 
them  to  pertain  to  a  certain  type.  The  type  system  of  VeriML  guarantees  that  these  functions  are  safe  to 
trust:  that  is,  if  they  return  successfully,  the  missing  part  of  the  proof  object  can  indeed  be  filled  in. 
Seen  as  proof  certificates,  they  address  the  impracticality  of  proof  objects,  without  imposing  an  increased 
trusted  base:  their  size  is  considerably  smaller,  validating  them  is  fast  as  the  missing  parts  do  not  need  to 
be  reconstructed,  yet  an  absolutely  skeptical  third  party  is  indeed  able  to  perform  this  reconstruction. 

We  have  seen  the  conversion  rule  as  an  example  of  these  simple  yet  tedious  steps  that  are  replaced  by 
calls  to  verified  VeriML  functions.  More  generally,  we  refer  to  the  mechanism  of  avoiding  such  steps  as 
small-scale  automation.  The  defining  characteristics  of  small-scale  automation  are:  it  is  used  to  automate 
ubiquitous,  yet  simple  steps;  therefore  the  VeriML  functions  that  we  can  use  should  be  relatively  inexpen¬ 
sive ;  as  our  earlier  discussion  shows,  the  calls  to  small-scale  automation  tactics  can  be  made  invisible  to 
the  programmer,  and  therefore  happen  implicitly,  and  we  expect,  in  the  standard  case,  that  small-scale  au¬ 
tomation  functions  are  evaluated  through  proof-erasure  semantics  and  therefore  do  not  leave  a  trace  in  the 
produced  proof  object.  We  have  also  made  the  choice  of  evaluating  small-scale  automation  statically.  In  this 
way,  after  stage-one  evaluation,  small-scale  automation  has  already  been  checked.  Based  on  this  view,  our 
insight  is  that  proof  objects  in  xHOLc  should  actually  be  seen  as  proof  object  expressions,  albeit  where  a 
specific  small-scale  automation  procedure  is  used,  which  is  fixed  a  priori. 

What  about  proof  expressions?  We  have  defined  them  earlier  as  VeriML  expressions  of  propositional 
type  and  which  therefore  evaluate  to  a  proof  object.  In  these  expressions  we  are  free  to  use  any  VeriML 
proof-producing  function,  evaluated  either  statically  or  dynamically,  through  proof-erasure  semantics  or 
not.  Indeed,  proof  object  expressions  are  meant  to  be  seen  as  a  special  case  of  proof  expressions,  where 
only  static  calls  to  (user-specified)  small-scale  automation  functions  are  allowed  and  evaluated  under  proof- 
erasure  semantics.  The  main  distinction  is  that  proof  expressions  can  also  use  other,  potentially  expensive, 
automated  proof-search  functions.  Using  arbitrary  proof  expressions  as  proof  certificates  would  thus 
not  be  desirable  despite  their  compactness,  as  the  receiving  third  party  would  have  to  perform  lengthy 
computation.  We  refer  to  these  extra  automation  mechanisms  that  can  be  used  in  proof  expressions  as 
large-scale  automation. 

The  distinction  between  small-  and  large-scale  automation  in  VeriML  might  seem  arbitrary,  but  indeed 
it  is  deliberately  so:  the  user  should  be  free  to  decide  what  constitutes  trivial  detail,  taking  into  account 
the  complexity  of  the  domain  they  are  working  on  and  of  the  automation  functions  they  have  developed. 
There  is  no  special  provision  that  needs  to  be  taken  in  order  to  render  a  VeriML  proof  automation  function 
part  of  small-scale  automation,  save  perhaps  for  syntactic  sugar  to  hide  its  uses.  Typing  is  therefore  of 
paramount  importance  in  moving  freely  between  the  two  kinds  of  automation:  in  the  case  of  small-scale 
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automation,  the  fact  that  calls  to  tactics  are  made  implicitly,  means  that  all  the  relevant  information  must 
be  inferred  through  the  type  system  instead  of  being  explicitly  specified  by  the  user.  It  is  exactly  this 
inferrence  that  the  VeriML  type  system  permits. 

Contrasting  proof  expressions  with  proof  scripts  reinforces  this  point.  Proof  scripts  in  traditional 
proof  assistants  are  similar  to  VeriML  proof  expressions,  where  all  the  logic-related  typing  information 
is  absent.  [This  is  why  we  refer  to  VeriML  proof  expressions  as  typed  proof  scripts  as  well.]  Since  the 
required  typing  information  is  missing,  the  view  of  small-scale  vs.  large-scale  automation  as  presented 
above  is  impossible  in  traditional  proof  assistants.  Another  way  to  put  this,  is  that  individual  proof  steps 
in  proof  scripts  depend  on  information  that  is  not  available  statically,  and  therefore  choosing  to  validate 
certain  proof  steps  ahead  of  time  (i.e.  calls  to  small-scale  automation  tactics)  is  impossible. 

7.2  User-extensible  static  checking  for  tactics 

In  the  previous  section  we  presented  a  novel  treatment  of  the  conversion  rule  which  allows  safe  user 
extensions.  Uses  of  the  conversion  rule  are  replaced  with  special  user-defined,  type-safe  tactics,  evaluated 
statically  and  under  proof  erasure  semantics.  This  leads  to  a  new  notion  of  proof  certificate,  which  we 
referred  to  as  proof  object  expressions.  The  main  question  we  will  concern  ourselves  with  in  this  section 
is  what  happens  when  the  proof  object  expression  is  contained  within  a  VeriML  function  and  is  therefore 
open,  instead  of  being  a  closed  expression:  can  we  still  check  its  validity  statically? 

Upon  closer  scrutiny,  another  way  to  pose  the  same  question  is  the  following:  can  we  evaluate  VeriML 
proof-producing  function  calls  during  stage-one  evaluation?  The  reason  this  question  is  equivalent  is  that 
the  conversion  rule  is  implemented  as  nothing  other  than  normal  VeriML  functions  that  produce  proofs 
of  a  certain  type. 

We  will  motivate  this  question  through  a  specific  usage  case  where  it  is  especially  useful.  When  devel¬ 
oping  a  new  extension  to  the  conversion  rule,  the  programmer  has  to  solve  a  number  of  proof  obligations 
witnessing  the  claimed  equivalences  -  remember  the  obligations  denoted  as  G-  in  Code  Listings  7. 1  and 
7.2.  Ideally,  we  would  like  to  solve  such  proof  obligations  with  minimal  manual  effort,  through  a  call  to  a 
suitable  proof-producing  function.  Yet  we  would  like  to  know  whether  these  obligations  were  successfully 
proved  at  the  definition  time  of  the  tactic,  i.e.  statically  -  rather  than  having  the  function  fail  seemingly 
at  random  upon  a  specific  invocation.  The  way  to  achieve  this  is  to  use  static  evaluation  for  the  function 
calls. 

A  rewriter  for  plus.  Let  us  consider  the  case  of  developing  a  rewriter  -similar  to  rewriteBetaNatStep- 
for  simplifying  expressions  of  the  form  x  +  y  depending  on  the  second  argument.  We  will  then  register 
this  rewriter  with  defEqual,  so  that  such  simplifications  are  automatically  taken  into  account  as  part  of 
definitional  equality. 

The  addition  function  is  defined  by  induction  on  the  first  argument,  as  follows: 

(+)  =  Xx.Xy.elimNaty  ( Xp.Xr.succ  r)  x 

Based  on  this  definition,  it  is  evident  that  defEqual,  that  is,  the  definitional  equality  tactic,  presented  al¬ 
ready  in  the  previous  section  performs  simplification  based  on  the  first  argument,  allowing  the  conversion 
rule  to  decide  implicitly  that  ( succ  x)  +  y  =  succ  (x  +  y)  or  even  that  ( succ  zero)  +  (x  +  y)  =  succ  (x+y). 
With  the  extension  we  will  describe  here,  similar  equivalences  such  as  %  +  ( succy )  =  succ(x  +y)  will  also 
be  handled  by  definitional  equality. 
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type  rewriterT  =  (<f> :  ctx,  T  :  Type,  E  :  T)  — *■  ( E ' :  T)  x  {E  =  £7) 


plusRewriterl :  rewriterT  — *  rewriterT 
plusRewriterl  recurse  <f>T  E  = 
holmatch  E  with 
X  +  Y  -*• 


let 

let 


(  n  Hx  :  Y 

=  Y'  j  =  recurse  <j>  Y  in 

{E',  H2:  X  +  Y'  =  E'  }  = 

holmatch  Y1  with 

zero  >->■ 

'  X,Gx:  X  +  zero  =  X  ) 

|  succ  Y'  >— ► 

^  succ  (X  +  Y'),  G2  :  A  +  succ  Y'  =  succ  (X  +  Y') 

\y 

'  X  +  Y',  G3 :  A  +  Y'  =  A  +  Y'  \ 

in 


(E\  G4:  X  +  F  =  £/ 
|£  ~  (E,  G5:  E=E  ) 


Code  Listing  7.3:  VeriML  rewriter  that  simplifies  uses  of  the  natural  number  addition  function  in  logical 
terms 

We  give  the  code  of  this  rewriter  as  the  plusRewriterl  function  in  Code  Listing  7.3.  In  order  for 
rewriters  to  be  able  to  use  existing  as  well  as  future  rewriters  to  perform  their  recursive  calls,  we  write  them 
in  the  open  recursion  style  -  they  receive  a  function  of  the  same  type  that  corresponds  to  the  “current” 
rewriter.  As  always,  we  have  noted  the  types  of  proof  hypotheses  and  obligations  in  the  program  text;  it 
is  understood  that  this  information  is  not  part  of  the  actual  text  but  can  be  reported  to  the  user  through 
interactive  use  of  the  VeriML  type  checker.  Contrary  to  our  practice  so  far,  in  this  code  we  have  used 
only  capital  letters  for  the  names  of  logical  metavariables.  This  we  do  in  order  to  have  a  clear  distinction 
between  normal  logical  variables,  denoted  through  lowercase  letters,  and  metavariables. 

How  do  we  fill  in  the  missing  obligations?  For  the  interesting  cases  of  X  +zero  =  X  and  X  +succ  Y1  = 
succ  (X  +  Y'),  we  would  certainly  need  to  prove  the  corresponding  lemmas.  But  for  the  rest  of  the  cases, 
the  corresponding  lemmas  would  be  uninteresting  and  tedious  to  state  and  prove,  such  as  the  following 
for  the  G4  :  X  +  Y  =  E'  case: 

lemmal :  ^  x,y,y'  ,e'  .y  =  y'  — *  (x  +  y'  =  e1)  — *■  x  +y  =  e' 

=  Xx,y,y' ,  e' ,Ha,Hj).conv Hy  {subst  {z.x  +  z  =  e')  {symrn  Ha)) 

G4  =  lemmal  XYY'E'  Hx  H2 

An  essentially  identical  alternative  would  be  to  directly  fill  in  the  proof  object  for  G4  instead  of  stating 
the  lemma: 

G4  =  conv  H2  { subst  (z.X  +  z  =  E')  { symrn  Hx)) 

Still,  stating  and  proving  such  lemmas,  or  writing  proof  objects  explicitly,  soon  becomes  a  hindrance 
when  writing  tactics.  A  better  alternative  is  to  use  the  congruence  closure  conversion  rule  to  solve  this 
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trivial  obligation  for  us  directly  at  the  point  where  it  is  required.  Assuming  that  the  current  req Equal 
function  includes  congruence  closure  as  part  of  definitional  equality,  our  first  attempt  to  do  this  would 
be: 


The  benefit  of  this  approach  is  more  evident  when  utilizing  implicit  arguments,  since  many  details  can 
be  inferred  and  therefore  omitted.  Here  we  had  to  alter  the  environment  passed  to  require  Equal,  which 
includes  several  extra  hypotheses.  Once  the  resulting  proof  has  been  computed,  the  hypotheses  are  sub¬ 
stituted  by  the  actual  proofs  that  we  have. 


Moving  to  static  proof  expressions.  This  is  where  using  the  letstatic  construct  becomes  essential.  We 
can  evaluate  the  call  to  req  Equal  statically,  during  stage  one  interpretation.  Thus  we  will  know  at  the  time 
that  plusRewriterl  is  defined  whether  the  call  succeeded;  also,  it  will  be  replaced  by  a  concrete  value,  so  it 
will  not  affect  the  runtime  behavior  of  each  invocation  of  plusRewriterl  anymore.  To  do  that,  we  need  to 
avoid  mentioning  any  of  the  metavariables  that  are  bound  during  runtime,  like  X,  Y,  and  E' .  This  is  done 
by  specifying  an  appropriate  environment  in  the  call  to  reqEqual,  similarly  to  the  way  we  incorporated 
the  extra  knowledge  above  and  substituted  it  later.  Using  this  approach,  we  have: 

G4  =  letstatic  (H )  = 

let  —  \x,y,y' ,e' :  Nat,  hl:y  =  y',h2:x+y'  =  e']  in 
requireEqual  (x  +y)  t' 

in  (  [^HliXIid^Ylid^riid^E'lid^HJid^lid^]  ) 

What  we  are  essentially  doing  here  is  replacing  the  meta-variables  by  normal  logical  variables,  which 
our  tactics  can  deal  with.  The  meta-variable  context  is  “collapsed”  into  a  normal  context;  proofs  are 
constructed  using  tactics  in  this  environment;  last,  the  resulting  proofs  are  transported  back  into  the 
desired  context  by  substituting  meta-variables  for  variables.  We  have  explicitly  stated  the  substitutions 
in  order  to  distinguish  between  normal  logical  variables  and  meta-variables.  In  the  actual  program  code, 
most  of  these  details  can  be  omitted. 

The  reason  why  this  transformation  needs  to  be  done  is  that  functions  in  our  computational  language 
can  only  manipulate  logical  terms  that  are  open  with  respect  to  a  normal  variables  context;  not  logical 
terms  that  are  open  with  respect  to  the  meta-variables  context  too.  A  much  more  complicated,  but  also 
more  flexible  alternative  to  using  this  “collapsing”  trick  would  be  to  support  meta” -variables  within  our 
computational  language  directly. 

It  is  worth  noting  that  the  transformation  we  describe  here  is  essentially  the  collapsing  transformation 
we  have  detailed  in  Section  5.2.  Therefore  this  transformation  is  not  always  applicable.  It  is  possible  only 
under  the  conditions  that  we  describe  there  -  roughly,  that  all  involved  contextual  terms  must  depend  on 
the  same  variables  context  and  use  the  identity  substitution. 

Overall,  this  approach  is  entirely  similar  to  proving  the  auxiliary  lemma  lemmal  mentioned  above, 
prior  to  the  tactic  definition.  The  benefit  is  that  by  leveraging  the  type  information  together  with  type 
inference,  we  can  avoid  stating  such  lemmas  explicitly,  while  retaining  the  same  runtime  behavior.  We 
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natlnduction:  (<f> :  ctx,  P  :  [<f>\  Nat  — >  Prop)  — ► 

(Hz  :  P  0,  Hs  :  V n.P  n  —*  P  ( succ  n))  —>  (\/n.P  n) 

instantiate  :  (<f> :  ctx,  T  :  Type,  P  :[<j>,  x:  T]Prop )  — > 

(H:Vx.P,  a:  T)^(P/[a/x]) 

plusRewriterl  :  rewriterT  — >  rewriterT 
plusRewriterl  recurse  <f>T  E  = 
holmatch  E  with 
X  +  Y  -*• 


II 

}  = 

X  +  Y'-- 

-E' 

holmatch  Y'  with 
zero  (X,  {{instantiate (natlnduction  reqEqual  reqEqual)X}} 

:  X  +  zero  =  X  ^ 

|  succ  Y'  i->  (  succ  ( X  +  Fx), 

{{instantiate (natlnduction  reqEqual  reqEqual)X}} 


in 


Code  Listing  7.4:  VeriML  rewriter  that  simplifies  uses  of  the  natural  number  addition  function  in  logical 
terms,  with  proof  obligations  filled-in 

thus  end  up  with  very  concise  proof  expressions  to  solve  proof  obligations  within  tactics,  which  are 
statically  validated.  We  introduce  syntactic  sugar  for  binding  the  result  of  a  static  proof  expression  to  a 
variable,  and  then  performing  a  substitution  to  bring  it  into  the  current  context,  since  this  is  a  common 
operation. 

{{e}}  =  letstatic  (H)  =  e  in  (  \<f>]H/a  ) 

More  details  of  how  this  construct  works  are  presented  in  Subsection  8.3.1.  For  the  time  being,  it  will 
suffice  to  say  that  it  effectively  implements  the  collapsing  transformation  for  the  logical  terms  involved  in 
e  and  also  fills  in  the  a  substitution  to  bring  the  collapsed  proof  object  back  to  the  required  context. 

Based  on  these,  the  trivial  proofs  in  the  above  tactic  can  be  filled  in  using  a  simple  {{reqEqual}}  call. 
The  other  two  we  actually  need  to  prove  by  induction.  We  give  the  full  code  with  the  proof  obligations 
filled  in  Code  Listing  7.4;  we  use  implicit  arguments  to  omit  information  that  is  easy  to  infer  through 
typing  and  end  up  with  very  concise  code. 

After  we  define  plusRewriterl,  we  can  register  it  with  the  global  equivalence  checking  procedure. 
Thus,  all  later  calls  to  reqEqual  will  benefit  from  this  simplification.  It  is  then  simple  to  prove  commuta- 
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tivity  for  addition: 

plusComm  :  (Vx,y.x  +  y  =y  +  x) 

plusComm  =  Natlnduction  reqEqual  reqEqual 

Based  on  this  proof,  we  can  write  a  naive  rewriter  that  takes  commutativity  into  account  and  uses  the 
hash  values  of  logical  terms  to  avoid  infinite  loops;  similarly  we  can  handle  associativity  and  distributiv- 
ity  with  multiplication.  Such  rewriters  can  then  be  used  for  a  better  arithmetic  simplification  rewriter, 
where  all  the  proofs  are  statically  solved  through  the  naive  rewriters.  The  simplifier  works  by  converting 
expressions  into  a  list  of  monomials,  sorting  the  list  based  on  the  hash  values  of  the  variables,  and  then 
factoring  monomials  on  the  same  variable.  Also,  the  eufEqual  procedure  mentioned  earlier  has  all  of  its 
associated  proofs  automated  through  static  proof  expressions,  using  a  naive,  potentially  non-terminating, 
equality  rewriter.  In  this  way,  we  can  separate  the  ‘proving’  part  of  writing  an  extension  to  the  conversion 
rule  -  by  incorporating  into  a  rewriter  with  a  naive  mechanism  -  from  its  ‘programming’  part  -  where  we 
are  free  to  use  sophisticated  data  structures  and  not  worry  about  the  generated  proof  obligations.  More 
details  about  these  can  be  found  in  Chapter  9. 

Formal  statement.  Let  us  return  now  to  the  question  we  asked  at  the  very  beginning  of  this  section: 
can  we  statically  check  proof  object  expressions  that  are  contained  within  VeriML  functions  -  that  is,  that 
are  open  with  respect  to  the  extension  variable  context  T?  The  answer  is  perhaps  obvious:  yes,  under  the 
limitations  about  collapsable  terms  that  we  have  already  seen.  We  will  now  state  this  with  more  formal 
detail. 

Let  us  go  back  to  the  structure  of  proof  object  expressions,  as  presented  in  Section  7.1.  We  have 
defined  them  as  VeriML  expressions  of  the  form: 

letstatic  Gt  =  [[reqEqual  Prop P1  P'J  in 

letstatic  Gn  =  [[reqEqual  $n  Prop Pn  P'J  in 

(^e) 

The  main  limitation  to  checking  such  expressions  statically  comes  from  having  to  evaluate  the  calls  to 
reqEqual  statically:  if  the  logical  terms  Pn  P-  involve  metavariables,  their  value  will  only  be  known  at 
runtime.  But  as  we  have  seen  in  this  chapter,  if  these  logical  terms  are  collapsable,  we  are  still  able  to 
evaluate  such  calls  statically,  after  the  transformation  that  we  described.  Therefore  we  are  still  able  to 
check  open  proof  object  expressions  statically,  if  we  use  the  special  {{•}}  construct  to  evaluate  the  calls  to 
reqEqual: 

let  Gj  =  [[  [reqEqual  Prop  Px  P'J  £jj  in 

letG"  =  {{[reqEq ua\$nPropP„P'nJE}}  in 

(nE) 

Based  on  this,  we  can  extend  the  lemma  7.1.2  to  open  /HOLc  proof  objects  as  well. 
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Lemma  7.2.1  (Extension  of  Lemma  7.1.2)  (\HOLc  proof  object  -  VeriML  proof  object  expression  equiva¬ 
lence) 

T;  $  bc  nc  :  P  collapsable  (T;  $  bc  nc  :  P)  J'L;  $  bc  nc  :  PJ  =  en 

*|-ert:([$]P)  — ►*  e'n 

2  *^e7r:([^]P)  en — fe^  •  b  :  T 

e'n  ■  — »*  (nE)  •;  $  •  \~E  nE  :  P  • 

Proof.  Straightforward  by  the  adaptation  of  the  translation  of  dHOLc  proof  object  to  proof  object 
expressions  suggested  above;  the  feasibility  of  this  adaptation  is  proved  directly  through  Theorem  5.2.4. 
The  second  part  is  proved  directly  by  the  form  of  the  proof  object  expressions  en  (a  series  of  let  •  •  •  in  con¬ 
structs),  which  based  on  the  semantics  of  VeriML  and  its  progress  theorem  always  evaluate  successfully. 
□ 

Let  us  describe  this  lemma  in  a  little  bit  more  detail.  The  first  part  of  the  lemma  states  that  we  can 
always  translate  an  open  (with  respect  to  the  extension  variables  context  T)  dHOLc  proof  object  to 
an  open  VeriML  proof  object  expression  of  the  same  type.  Also,  that  the  expression  is  guaranteed  to 
successfully  evaluate  statically  into  another  expression,  instead  of  throwing  an  exception  or  going  into  an 
infinite  loop.  Informally,  we  can  say  that  the  combination  of  typing  and  static  evaluation  yields  the  same 
checking  behavior  as  typing  for  the  original  dHOLc  proof  object.  Formally,  static  evaluation  results  in 
an  expression  e'  and  not  a  value;  it  would  not  be  possible  otherwise,  since  its  type  contains  extension 
variables  that  are  only  instantiated  at  runtime.  Thus  it  would  still  be  possible  for  the  expression  to  fail 
to  evaluate  successfully  at  runtime,  which  would  destroy  the  informal  property  we  are  claiming.  This  is 
why  the  second  part  is  needed:  under  any  possible  instantiation  of  the  extension  variables,  the  runtime 
e'  expression  will  evaluate  successfully  to  a  valid  dHOL£  proof  object. 

Overall  this  lemma  allows  us  one  more  way  to  look  at  VeriML  with  the  staging,  proof  erasure  and  col¬ 
lapsing  constructs  we  have  described.  First,  we  can  view  VeriML  as  a  generic  language  design  VeriML(X), 
where  X  is  a  typed  object  language.  For  example,  though  we  have  described  VeriML(dHOL£),  an  alter¬ 
nate  version  VeriML (dHOLc)  where  dHOLc  is  used  as  the  logic  is  easy  to  imagine.  The  main  VeriML 
constructs  -dependent  abstraction,  dependent  tuples  and  dependent  pattern  matching-  allow  us  to  manip¬ 
ulate  the  typed  terms  of  X  in  a  type-safe  way.  The  lemma  above  suggests  that  the  combination  of  staging, 
proof  erasure  and  collapsing  are  the  minimal  constructs  that  allow  us  to  retain  this  genericity  at  the  user 
level,  despite  the  a  priori  choice  of  XHOLe. 

What  we  mean  by  this  is  the  following:  the  lemma  above  shows  that  we  can  embed  /lHOLc  proof  ob¬ 
jects  within  arbitrary  VeriML(dHOL£)  expressions  and  still  check  them  statically,  even  though  dHOL£ 
does  not  include  an  explicit  conversion  rule  at  its  design  time.  Furthermore,  we  have  seen  how  further 
extensions  to  the  conversion  rule  can  be  checked  in  entirely  the  same  manner.  Therefore,  these  constructs 
allow  VeriML(dHOL£)  to  effectively  appear  as  VeriML(dHOL£+^)  to  the  user,  where  X  is  the  user-defined 
conversion  rule.  Last,  user-extensible  static  checking  does  not  have  to  be  limited  to  equivalences  as  we  do 
in  the  conversion  rule;  any  other  property  encodable  within  dHOL£  can  be  checked  in  a  similar  manner 
too.  Thus  the  combination  of  VeriML(dHOL£)  with  these  three  constructs  allow  the  user  to  treat  it  as 
the  language  VeriML (/lHOL£+X)  where  A  is  a  user-defined  set  of  properties  that  is  statically  checked  in 
a  user-defined  manner.  Put  simply,  VeriML  can  be  viewed  as  a  language  that  allows  user-extensible  static 
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checking. 

Of  course,  the  above  description  is  somewhat  marred  by  the  existence  of  the  side-condition  of  col¬ 
lapsable  logical  terms  and  therefore  does  not  hold  in  its  full  generality.  It  is  a  fact  that  we  cannot  stat¬ 
ically  prove  that  terms  containing  meta-variables  are  /3N-equi  valent;  this  would  be  possible  already  in 
the  VeriML(/HOLf)  version  of  the  language.  Lifting  this  side-condition  requires  further  additions  to 
VeriML,  such  as  substitution  variables  and  meta-meta-variables.  The  reason  is  that  VeriML  would  need  to 
manipulate  dHOLc  terms  that  are  open  not  only  with  respect  to  the  $  normal  variables  context,  but  also 
with  respect  to  the  T  metavariables  context,  in  order  to  support  type-safe  manipulation  of  terms  that  in¬ 
clude  metavariables.  For  example,  our  definitional  equality  tactic  would  have  roughly  the  following  form, 
where  we  have  only  written  the  metavariables-matching  case  and  include  the  context  details  we  usually 
omit: 

defEqual  :  (cp  :  ctx1,  <p  :  \p~\  ctx1)  — > 

(T:[m\Type,  tvt2  :  [<p\  [<p]  T) 
option  ([ip]  [(f)]  tx  =  t2) 

defEqual  (p  (f>T  tlt2  =  holmatch  tx,  t1  with 

(f  :  [<p]  ctx1,  X  :[$]  [f  ]  T\  s,s':  [^]  f  >  <P).X/s,  X / s'  ~ 
do  ^  H  :  \_cp1\s  =  s'  ^  <—  defEqualSubst  i p  <p'  <p  s  s' 
return  (  eqMetaX  H ) 

Though  the  principles  presented  in  our  technical  development  for  VeriML  could  be  used  to  provide  an 
account  for  such  extensions,  we  are  not  yet  aware  of  a  way  to  hide  the  considerable  extra  complexity  from 
the  user.  Thus  we  have  left  further  investigation  of  how  to  properly  lift  the  collapsing-related  limitation 
to  future  work. 

7.3  Programming  with  dependently-typed  data  structures 

In  this  section  we  will  see  a  different  application  of  the  static  checking  of  proof  expressions  that  we  pre¬ 
sented  in  the  previous  section.  We  will  show  how  the  same  approach  can  be  used  to  simplify  programming 
with  dependently-typed  data  structures  in  the  computational  part  of  VeriML,  similar  to  programming  in 
Haskell  with  GADTs  [Peyton  Jones  et  ah,  2006],  Though  this  is  a  tangent  to  the  original  application 
area  that  we  have  in  mind  for  VeriML,  namely  proof  assistant -like  scenarios,  we  will  see  that  in  fact  the 
two  areas  are  closely  related.  Still,  our  current  VeriML  implementation  has  not  been  tuned  to  this  usage 
scenario,  so  most  of  this  section  should  be  perceived  as  a  description  of  an  interesting  future  direction. 

First,  let  us  start  with  a  brief  review  of  what  dependently-typed  programming  is:  the  manipulation 
of  data  structures  (or  terms)  whose  type  depends  somehow  on  the  value  of  other  data  structures  -  that 
is,  programming  with  terms  whose  type  depends  on  other  terms.  The  standard  concrete  example  of  such 
a  data  structure  is  the  type  of  lists  of  a  specific  length,  usually  called  vectors  in  the  literature.  The  type 
of  a  vector  depends  on  a  type,  representing  the  type  of  its  elements  (similar  to  polymorphic  lists);  and  on 
the  value  of  a  natural  number  as  well,  representing  the  length  of  the  vector.  Vector  values  are  constrained 
through  this  type  so  that  only  vectors  of  specific  length  are  allowed  to  have  the  corresponding  type.  For 
example,  the  following  vector: 

[  "hello",  "world",  "!"  ] 
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has  type  vector  string  3.  We  write  that  the  kind  of  vectors  is: 

vector  :  *  — >  Nat  — ►  * 

We  remind  the  reader  that  stands  for  the  kind  of  computational  types.  The  definition  of  the  vector 
type  looks  as  follows: 

type  vector  (a  :  *)  (n  :  Nat)  =  nil  ::  vector  a  0 

j  cons  ::  a  —*■  vector  a  n  —*  vector  a  (succ  n) 

We  see  that  the  constructor  for  an  empty  vector  imposes  the  constraint  that  its  length  should  be  zero;  the 
case  for  prefixing  a  vector  with  a  new  element  constrains  the  length  of  the  resulting  vector  accordingly. 

The  dependently-typed  vector  datatype  offers  increased  expressiveness  in  the  type  system  compared 
to  the  simply-typed  list  datatype  familiar  from  ML  and  Haskell.  This  becomes  apparent  when  considering 
functions  that  manipulate  such  a  datatype.  By  having  the  extra  length  argument,  we  can  specify  richer 
properties  of  such  functions.  For  example,  we  might  say  that  the  head  and  tail  functions  on  vectors 
require  that  the  vector  be  non-empty;  that  the  map  function  returns  a  vector  of  the  same  length;  and  that 
append  returns  a  vector  with  the  number  of  elements  of  both  arguments.  Formally  we  would  write  these 
as  follows: 

head  :  vector  a  ( succ  n)  — >  vector  a  n 

tail  :  vector  a  (succ  n)  —*■  vector  a  n 

map  :  (a  —*  j3)  —*■  vector  a  n  — *■  vector  f3  n 

append  :  vector  a  n  —*■  vector  a  m  — *■  vector  a  (n  +  m) 

In  the  case  of  head,  this  allows  us  to  omit  the  redundant  case  of  the  nil  vector: 

head  /  =  match  /  with  cons  hd  tl  *-*  hd 

The  compiler  can  determine  that  the  nil-case  is  indeed  redundant,  as  vector  a  (n  +  1)  could  never  be 
inhabited  by  an  empty  vector  per  definition,  and  therefore  will  not  issue  a  warning  about  incomplete 
pattern  matching.  Furthermore,  the  richer  types  allow  us  to  catch  more  errors  statically.  For  example, 
consider  the  following  erroneous  version  of  map: 

map /  /  =  match  /  with 

nil  nil 

i  cons  hd  tl  let  hd;  =/ hd  in  map/ tl 

In  the  second  case,  the  user  made  a  typo,  forgetting  to  prefix  the  resulting  list  with  hdb  Since  the  resulting 
list  does  not  have  the  expected  length,  the  compiler  will  issue  an  error  when  type-checking  this  function. 

There  are  a  number  of  languages  supporting  this  style  of  programming.  Some  of  the  languages  that  pi¬ 
oneered  this  style  are  Cayenne  [Augustsson,  1999] ,  Dependent  ML  [Xi  and  Pfenning,  1999]  and  Epigram 
[McBride,  2005],  Modern  dependently-typed  languages  include  Haskell  with  the  generalized  abstract 
datatypes  extension  (GADTs)  [Peyton  Jones  et  ah,  2006],  Agda  [Norell,  2007]  and  Idris  [Brady,  2011], 
Various  logics  based  on  Martin-Lof  type  theory  such  as  CIC  as  supported  by  Coq  [Barras  et  ah,  2012]  and 
NuPRL  [Constable  et  ah,  1986]  support  dependently-typed  programming  as  well.  Coq  includes  a  surface 
language  specifically  for  this  style  of  programming,  referred  to  as  Russell  [Sozeau,  2006], 

VeriML  does  fall  under  the  definition  of  dependently-typed  programming:  for  example,  in  a  depen¬ 
dent  tuple  (P,  n),  the  type  of  the  proof  object  n  depends  on  the  (runtime)  value  of  P.  In  this  section  we 
will  show  that  it  can  indeed  encode  types  such  as  vector  exactly  as  presented  above  and  the  advantages  it 
offers  over  such  languages. 
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Behind  the  scenes.  Let  us  now  dig  deeper  into  what  is  happening  behind  the  scenes  in  the  type  checker 
of  a  compiler,  when  manipulating  dependently-typed  data  structures  such  as  vector.  We  will  start  with 
the  elimination  form,  namely  pattern  matching.  Consider  the  following  piece  of  code: 

append  l2  =  match  /,  with 

nil  i— >  ••• 

cons  hd  tl 

Just  as  in  the  simply-typed  version  of  lists,  in  each  branch  we  learn  the  top-most  constructor  used.  But 
in  the  dependently-typed  version,  we  learn  more  information:  namely,  that  the  length  of  the  list  (the 
dependent  argument  n)  is  zero  in  the  first  case;  and  that  it  can  be  written  as  n  =  succ  n  for  suitable  n  in 
the  second  case. 

This  information  might  be  crucial  for  further  typing  decisions.  Typing  imposes  additional  constraints 
on  the  length  of  resulting  lists,  as  the  type  of  the  example  append  functio  does.  To  show  that  these 
constraints  are  indeed  satisfied,  the  extra  information  coming  from  each  pattern  matching  branch  needs 
to  be  taken  into  account.  Similar  information  might  come  from  function  calls  yielding  dependent  data 
structures.  These  are  more  evident  when  we  consider  the  full  code  of  the  append  function: 

append  :  vector  a  n  — *■  vector  a  m  — *■  vector  a  (n  +  m) 
append  lx  l2  =  match  with 

nil  i— ►  l2 

■  cons  hd  tl  I-*  let  tl'  =  append  tl  l2  in 
cons  hd  tl' 

Let’s  annotate  this  code  with  all  the  information  coming  from  typing.  We  drop  the  polymorphic  type 
for  presentation  purposes. 

append  (/,  :  vector  n  )  (l2  :  vector  m  )  = 
match  l{  with 

nil  where  n  =  0  >— ► 

(l2  :  vector  m  ) 
j  cons  where  n  =  succ  n' 

\et(tV :  vector  (n/  +  m)  )  =  append  tl  l2  in 
(cons  hd  tl' :  vector  ( succ  ( n '  +  m ))  ) 

This  information  can  directly  be  figured  out  through  the  type  inference  algorithm  based  on  the 
already-available  information  about  the  dependent  terms,  using  adaptations  of  unification-based  mech¬ 
anisms  such  as  Algorithm  W  [Damas  and  Milner,  1982].  Yet  there  is  one  piece  missing  from  deeming 
the  above  code  well-typed:  we  must  ensure  that  the  type  of  the  returned  lists  in  both  branches  indeed 
satisfies  the  desired  type,  as  specified  in  the  type  signature  of  append.  Namely,  in  the  first  branch  we  need 
to  reconcile  the  type  vector  m  with  the  expected  type  vector  ( n  +  m);  similarly  for  the  second  branch, 
vector  (succ  (n'  +  m ))  needs  to  be  reconciled  with  vector  (n  +  m).  What  the  type  checker  essentially  needs 
to  do  is  prove  that  the  two  types  are  equal.  It  needs  to  make  sure  that  m  =  n  +  m  and  succ  ( n'+m)  =  n+m 
taking  into  account  the  extra  available  information  about  n  in  both  cases. 

Though  these  two  cases  might  seem  straightforward  conclusions  of  the  available  information,  it  is 
important  to  realize  that  the  proof  obligations  that  might  be  generated  in  such  dependently-typed  pro¬ 
grams  are  arbitrarily  complex.  It  is  important  for  users  to  be  able  to  specify  their  own  functions  such  as 


hd  (tl :  vector  n  ) 
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append  :  (n  :  Nat ,  /,  :  vector  n,  m  :  Xkf,  /2  :  vector  m)  — > 

(r  :  Xkt)  x  vector  r  x  (r  =  «  +  m) 

append  n  (/,  :  vector  n  )  m(l2:  vector  w  )  = 
match  /,  with 

nil(/fj  :  n  —  0  )  >-+ 

(ra,  l2,  Gj  :  m  —  n  m  ) 

j  cons(V,  hd,  tl :  vector  n'  ,  H2:  n  =  succ  n'  )  >-* 

let(r/,  tl' :  vector  r'  =  +  tn  )  =  append  tl  l2  in 

(«,  cons  hd  tl' ,  G2  :  s«cc  r'  =  «  +  w  ) 


Code  Listing  7.5:  Version  of  vector  append  with  explicit  proofs 

+  and  predicates  other  than  the  implicit  equality  constraints  shown  above,  in  order  to  be  able  to  capture 
precisely  the  properties  that  they  want  the  dependent  data  structures  to  have.  Taking  these  into  account, 
it  is  evident  that  proving  the  generated  proof  obligations  involves  proving  theorems  about  functions  such 
as  +  and  predicates  such  as  less-than.  Thus  discharging  the  proof  obligations  automatically  is  undecidable 
in  the  general  case,  if  we  allow  a  rich  enough  set  of  properties  to  be  captured  at  the  type  level. 

In  summary,  we  might  say  that  positive  occurrences  of  dependent  terms,  such  as  in  the  body  of  a  func¬ 
tion  or  of  a  let  declaration,  are  associated  with  proof  obligations ;  negative  occurrences,  such  as  in  a  pattern 
matching  branch  or  in  the  binding  part  of  a  let  declaration,  yield  proof  hypotheses-,  and  that  type-checking  of 
dependent  terms  is  intermixed  with  theorem  proving  to  discharge  the  generated  proof  obligations3.  The 
astute  reader  familiar  with  ML -style  languages  might  note  that  such  a  view  is  even  true  for  polymorphic 
types  in  the  presence  of  existential  types  (e.g.  through  the  ML  module  system).  Yet  in  that  case  we  are 
only  dealing  with  syntactic  equality,  rendering  a  decidable  decision  procedure  for  the  theorem  proving 
part  feasible. 

Explicit  version.  Based  on  the  above  discussion,  we  can  provide  an  intermediate  representation  of 
dependently-typed  programs  where  the  proof-related  parts  are  explicitly  evident.  For  example,  the  im¬ 
plicit  equality  constraints  in  the  type  of  vector’s  constructors  and  in  the  type  of  append  can  be  viewed 
instead  as  requiring  explicit  proof  terms  for  the  equalities.  Such  a  representation  was  first  presented  by 
Xi  et  al.  [2003]  in  order  to  reconcile  the  GADT-style  definitions  with  ML -style  definitions  of  data  types: 
instead  of  explicitly  assigning  a  type  to  each  constructor,  each  constructor  can  be  presented  as  a  list  of 
components,  some  of  which  are  explicit  equality  constraints.  Still,  recent  work  [e.g.  Goguen  et  ah,  2006, 
Sulzmann  et  ah,  2007,  Schrijvers  et  ah,  2009,  Vytiniotis  et  ah,  2012]  suggests  that  this  representation  is 
more  fundamental;  the  current  version  of  the  GHC  compiler  for  Haskell  actually  uses  the  explicit  version 
and  even  keeps  the  equality  proofs  in  subsequent  intermediate  languages  as  it  is  useful  for  compilation 
purposes. 

Based  on  the  above,  we  give  the  explicit  version  of  the  definition  of  vector  becomes: 

3.  This  summary  assumes  let-normal  form  so  that  hypotheses  are  not  missed:  for  example,  writing  cons  hd  (append  tl  /,)  in 
the  second  branch  of  the  append  function  would  make  us  lose  the  information  about  the  length  of  the  returned  list.  Transforming 
this  into  let-normal  form  allows  us  to  capture  the  extra  information. 
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type  vector  a  n  = 


nil  of  {n  =  0) 

cons  of  ( n ' :  Nat)  x  a  x  vector  a  n'  x(n  =  succ  n1) 

Similarly,  the  explicit  version  of  append  assigns  names  to  hypotheses  and  notes  the  types  of  obligations 
that  need  to  be  proved;  we  present  it  in  Code  Listing  7.5.  It  is  quite  similar  to  our  fully-annotated  version 
from  above.  In  this  code  fragment  we  have  left  the  proof  obligations  G,  and  G1  unspecified;  we  have  only 
given  their  types.  In  the  real  version  of  the  code  they  would  need  to  be  replaced  by  sufficient  evidence  to 
show  that  the  proof  obligations  indeed  hold. 

We  have  on  purpose  used  syntax  close  to  the  one  we  use  in  VeriML.  In  fact,  the  above  two  code  frag¬ 
ments  can  be  directly  programmed  within  VeriML,  showing  that  VeriML  can  be  used  for  the  style  of 
dependently-typed  programming  supported  by  languages  such  as  Haskell  at  its  computational  level.  Do¬ 
main  objects  of  xHOL  such  as  natural  numbers  can  be  used  as  dependent  arguments  (also  called  dependent 
indexes );  dHOL  propositions  can  be  used  to  ascribe  constraints  to  such  arguments;  and  xHOL  proof  ob¬ 
jects  can  be  used  as  evidence  for  the  discharging  of  proof  obligations.  All  of  the  involved  dHOL  terms  are 
closed  and  the  contextual  terms  support  is  not  required  for  this  style  of  programming.  Note  that  while  the 
dependent  indexes  are  at  the  level  of  the  logical  language,  dependent  types  such  as  vector  are  part  of  the 
ML-style  computational  level  of  VeriML.  The  full  expressiveness  of  dHOL  is  available  both  for  defining 
the  types  of  dependent  indexes  and  for  defining  their  required  properties. 

To  show  that  the  above  encoding  of  the  dependent  vector  datatype  does  not  need  any  new  features  in 
VeriML,  let  us  give  its  fully  explicit  version  with  no  syntactic  sugar,  following  the  language  definition  in 
Chapter  6: 

vector  =  Aa  :  *./ut :  ([]  Nat)  — >  *.AN  :  []  Nat. 

([]  N  =  zero )  +  ((N' :  []  Nat)  x  a  x  t  N'  x([]N  =  succ  A7)) 

One  question  remains:  how  do  we  go  from  the  simply-typed  presentation  of  dependent  programs 
as  shown  above  to  the  explicit  version  presented  here?  By  comparison  of  the  two  versions  of  the  code 
of  append  we  identify  two  primary  difficulties,  both  related  to  positive  occurrences  of  dependent  terms: 
first,  we  need  to  ‘invent’  instantiations  for  the  indexes  -  e.g.  for  the  length  of  the  vectors  returned;  second, 
we  need  to  discharge  the  proof  obligations.  As  suggested  above,  the  instantiations  for  the  indexes  can 
be  handled  through  type  inferrence  using  a  unification-based  algorithm,  assuming  that  sufficient  typing 
annotations  are  available  from  the  context;  though  limiting  the  number  of  required  annotations  is  an 
interesting  research  problem  in  itself  [e.g.  Peyton  Jones  et  ah,  2006],  we  will  not  be  further  concerned 
with  this.  The  latter  problem,  discharging  proof  obligations  such  as  G,  and  G2  in  append,  amounts  to 
general  theorem  proving  as  discussed  above  and  is  therefore  undecidable.  We  will  now  focus  on  approaches 
to  handling  this  problem. 

Options  for  discharging  obligations.  The  first  option  we  have  with  respect  to  discharging  obligations 
is  to  restrict  their  form,  so  that  the  problem  becomes  decidable.  For  example,  Dependent  ML  restricts 
indices  to  be  natural  numbers  and  the  obligations  to  be  linear  equalities.  The  type-checker  might  then 
employ  a  decision  procedure  for  deciding  the  validity  of  all  the  obligations.  If  the  decision  procedure  is 
proof-producing,  such  calls  are  viewed  as  part  of  elaboration  of  the  surface-level  program  into  the  explicit 
version,  where  obligations  such  as  Gj  and  G2  are  actually  filled  in  with  the  proof  returned  through  the 
decision  procedure.  The  benefit  of  this  choice  is  that  it  requires  no  special  user  input  in  order  to  discharge 
obligations;  the  obvious  downside  is  that  the  expressibility  of  the  dependent  types  is  severely  limited.  If  we 
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take  the  view  that  dependently-typed  programming  is  really  about  being  able  to  define  data  structures  with 
user-defined  invariants  and  functions  with  user-defined  pre-  and  post -conditions,  it  is  absolutely  critical 
that  we  have  an  expressive  logic  in  order  to  describe  them;  this  is  something  that  this  option  entirely 
precludes. 

A  second  option  is  to  have  the  user  give  full,  explicit  evidence  that  the  proof  obligations  hold  by  pro¬ 
viding  a  suitable  proof  object.  This  is  the  other  end  of  the  spectrum:  it  offers  no  automation  with  respect 
to  discharging  obligations,  yet  it  offers  maximum  extensibility  -  programs  with  arbitrarily  complex  proof 
obligations  can  be  deemed  well-typed,  as  long  as  proofs  exist  (and  the  user  can  somehow  discover  it).  The 
proof  objects  can  be  rather  large  even  for  simple  proof  obligations,  therefore  this  choice  is  clearly  not  suit¬ 
able  for  a  surface  language.  The  maximum  expressivity  and  the  ease  of  type-checking  makes  this  choice 
well-suited  for  compiler  intermediate  languages;  indeed,  GHC  uses  this  form  as  mentioned  above. 

In  practice,  most  dependently-typed  languages  offer  a  mix  between  these  two  choices,  where  some 
obligations  are  solved  directly  through  some  built-in  decision  procedures  and  others  require  user  input, 
in  the  form  of  explicit  proofs  or  auxiliary  lemmas.  For  example,  the  type  class  resolution  mechanism 
offered  by  Haskell  can  be  viewed  as  a  decision  procedure  for  Prolog-style  obligations  (first-order  minimal 
logic  with  uninterpreted  functions);  the  conversion  rule  in  languages  such  as  CIC  or  Agda,  as  noted  in 
Section  7.1,  can  be  viewed  as  a  decision  procedure  for  /3 '-equality;  languages  with  an  extended  conversion 
rule  such  as  CoqMT  also  include  decision  procedures  for  arithmetic  and  other  first-order  theories;  and 
last,  dependent  pattern  matching  as  supported  by  languages  such  as  Agda  or  Idris  can  be  viewed  as  pro¬ 
viding  a  further  decision  procedure  over  heterogeneous  equality.  All  these  languages  also  provide  ways  to 
give  an  explicit  proof  object  in  order  to  discharge  specific  proof  obligations  arising  in  dependently-typed 
programs.  Still,  the  automation  offered  in  these  languages  falls  short  of  user  expectations  in  many  cases: 
for  example,  while  the  above  version  of  append  would  be  automatically  found  to  be  well-typed  in  all  these 
languages,  the  version  where  the  arguments  are  flipped  is  only  well-typed  in  CoqMT  and  requires  explicit 
proof  in  others.  This  fact  is  especially  true  as  the  properties  specified  for  dependent  indices  become  more 
complex. 

Yet  another  choice  is  to  use  the  full  power  of  a  proof  assistant  in  order  to  discharge  obligations.  This 
choice  is  primarily  offered  by  the  Russell  language,  which  is  a  surface  language  in  Coq  specifically  for  writ¬ 
ing  dependently-typed  programs.  It  allows  the  user  to  write  the  simply-typed  version  of  such  programs,  as 
we  did  before  for  append;  during  elaboration,  the  generated  proof  obligations  are  presented  to  the  user  as 
goals;  after  the  user  has  solved  all  the  goals,  the  fully  explicit  dependently-typed  version  is  emitted.  Obli¬ 
gations  are  first  attempted  to  be  solved  through  a  default  automation  (semi-)decision  procedure.  They  are 
only  presented  to  the  user  if  the  decision  procedure  fails  to  solve  them,  in  which  case  the  user  can  develop 
a  suitable  proof  script  in  the  interactive  style  offered  by  Coq.  We  consider  this  approach  to  be  the  current 
state-of-the-art:  it  offers  a  considerable  amount  of  automation;  it  is  maximally  expressive,  as  the  user  is 
always  free  to  provide  a  proof  script;  it  separates  the  programming  part  clearly  from  the  proof-related 
part;  and,  most  importantly,  the  amount  of  automation  offered  is  user-extensible.  This  last  point  is  true 
because  the  user  can  specify  their  own  more  sophisticated  automation  decision  procedure  to  be  used  as 
the  ‘default’  one. 

Our  main  point  in  this  section  is  that  VeriML  offers  this  same  choice,  yet  with  a  significant  improve¬ 
ment:  proof  obligations  can  be  discharged  through  statically-evaluated  calls  to  decision  procedures;  but 
the  decision  procedures  themselves  can  be  programmed  within  the  same  language.  First,  we  can  use  the  same 
mechanism  used  in  the  previous  section  for  statically  discharging  obligations.  Consider  the  following 
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version  of  append  within  VeriML: 

append  :  (n  :  Nat,  lx  :  vector  n,  m  :  Nat,  l2  :  vector  m)  —> 

( r  :  Nat)  x  vector  r  x  (r  =  n  +  m) 

append  n  (/,  :  vector  n  )m(l2:  vector  m  )  = 
match  /j  with 

nil(//j  :  n  =  0  )  i-* 

(pm,  l2,  {{Auto}}  :  (m  =  n  +  m)  ) 
j  cons}?/,  M,  tl :  vector  n'  ,  H2:  n  =  smcc  n'  )  >-*■ 

let  (r',tl'\  vector  r'  ,  H3 :  r'  =  n'  +  nr  )  =  append  tl  l2  in 
(«,  cons  hd  tl' ,  {{Auto}}  :  (succ  r'  =  n  +  m)  ) 

Obligations  are  discharged  through  static  calls  to  the  Auto  function  of  the  type 

Auto  :  (cf> :  ctx,  P  :  Prop )  — *  (P) 

where  both  <f>  and  P  are  implicit  arguments.  The  collapsing  transformation  used  in  the  previous  section 
turns  the  extra  proof  hypotheses  Hl  through  Hi  into  elements  of  the  <f>  context  that  Auto  is  called  with. 
Thus  the  static  calls  to  the  function  can  take  this  information  into  account,  even  though  the  actual  proofs 
of  these  hypotheses  will  only  be  available  at  runtime.  Since  discharging  happens  during  stage-one  evalu¬ 
ation,  we  will  know  statically,  at  the  definition  time  of  the  append  function  whether  the  obligations  are 
successfully  discharged  or  not. 

The  departure  from  the  Russell  approach  is  subtle:  the  Auto  function  itself  is  written  within  the  same 
programming  language;  whereas  the  tactics  used  in  Russell  are  written  through  other  languages  provided 
by  Coq.  In  fact,  Auto  is  a  dependently-typed  function  in  itself.  Therefore,  some  of  its  proof  obligations 
can  be  solved  statically  and  automatically  through  another  function  and  so  on.  Another  way  to  view  this 
is  that  proof  obligations  generated  during  VeriML  type-checking  are  discharged  through  proof  functions  that 
are  written  in  VeriML  themselves.  Using  one  conversion  rule  to  help  us  solve  the  obligations  of  another,  as 
shown  in  the  previous  section,  is  one  example  where  this  idea  is  put  to  practice. 

VeriML  does  not  yet  offer  a  surface  language  for  dependently-typed  programming  similar  to  Russell, 
so  that  surface  programs  can  be  written  in  a  simply-typed  style.  Thus  for  the  time  being  developing  such 
programs  is  tedious.  Still,  such  an  extension  is  conceptually  simple  and  could  be  provided  through  typed 
syntactic  sugar.  As  suggested  above,  positive  occurrences  of  dependent  data  types  can  be  replaced  by  suit¬ 
able  dependent  tuples:  indices,  such  as  the  length  of  the  list  in  the  vector  example,  are  left  as  implicit 
arguments  to  be  inferred  by  type  checking;  and  proof  obligations  are  discharged  through  a  static  call  to 
a  default  automation  tactic.  Negative  occurrences  are  replaced  by  fully  unpacking  the  dependent  tuples 
and  assigning  unique  names  to  their  components,  so  that  they  can  be  used  in  the  rest  of  the  program.  Fur¬ 
thermore,  the  user  can  be  asked  to  explicitly  provide  a  proof  expression  if  one  of  the  static  tactic  calls  fail. 
Based  on  this,  type-checking  a  dependently-typed  program  has  a  fixed  part  (using  type  inference  to  infer 
missing  indices)  and  a  user-extensible  part  (using  the  automation  tactic  statically).  They  respectively  cor¬ 
respond  to  fixed  type-checking  and  user-extensible  static  evaluation,  resembling  the  case  of  the  extensible 
conversion  rule. 

Overall  the  VeriML  approach  to  dependently-typed  programming  described  here  leads  to  a  form  of 
extensible  type  checking :  dependent  types  offer  users  a  way  to  specify  rich  properties  about  data  structures 
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and  functions;  and  the  VeriML  constructs  offer  a  way  to  specify  how  to  statically  check  whether  these 
properties  hold  using  a  rich  programming  model.  We  believe  that  exploiting  this  possibility  is  a  promising 
future  research  direction. 

Further  considerations. 

We  will  now  draw  attention  to  further  issues  that  have  to  do  with  dependently-typed  programming  in 
VeriML  and  other  languages. 

Phase  distinction.  Throughout  the  above  discussion  we  have  made  a  silent  assumption:  the  notion  of 
indices  that  data  types  can  depend  on  is  distinct  from  arbitrary  terms  of  the  computational  language; 
furthermore,  some  logic  for  describing  such  properties  is  available.  Still,  our  initial  description  of  de¬ 
pendent  types  suggests  that  a  type  can  depend  on  an  arbitrary  term.  This  style  of  full  dependent  types 
poses  a  number  of  problems:  e.g.  what  happens  if  the  term  contains  a  non-terminating  function  appli¬ 
cation,  or  a  side-effecting  operation?  Non-termination  would  directly  render  type  checking  undecidable, 
as  the  compiler  could  be  stuck  for  arbitrarily  long  trying  to  prove  two  terms  equal.  Side-effects  would 
present  other  difficulties;  for  example,  type  checking  would  have  to  proceed  in  a  well-specified  order  so 
that  the  threading  order  of  side-effects  is  known  to  the  user.  Therefore  all  dependently-typed  languages 
support  restricted  forms  of  dependent  types.  The  only  exception  is  Cayenne,  one  of  the  earliest  proposals 
of  dependently-typed  languages,  which  was  plagued  by  the  problems  suggested  above.  Languages  such  as 
Dependent  ML  and  Haskell  with  GADTs  choose  to  only  allow  dependency  on  a  separate  class  of  terms 
-  the  indexes  as  used  throughout  our  discussion.  Languages  that  can  be  used  as  type-theoretic  logics  (Epi¬ 
gram,  Agda,  Idris,  Coq  etc.)  offer  an  infinite,  stratified  tower  of  universes,  where  values  in  one  universe 
are  typed  through  values  in  the  next  universe  and  dependency  is  only  allowed  from  higher  universes  into 
lower  ones.  They  also  restrict  computation  to  be  pure. 

The  main  idea  behind  dependent  data  types  in  languages  such  as  Dependent  ML  and  Haskell  with 
GADTs  is  to  allow  other  kinds  of  static  data  other  than  types;  it  is  exactly  these  static  data  that  are  referred 
to  as  indexes.  The  natural  number  n  representing  the  length  of  a  vector  in  the  example  given  above  is  such 
an  index;  its  classifier  Nat  is  now  viewed  as  a  kind  instead  of  as  a  type  of  a  runtime  value.  Indexes  exist 
purely  for  type-checking  purposes  and  can  be  erased  prior  to  runtime.  We  thus  understand  that  this  style 
of  dependently-typed  programming  preserves  the  phase  distinction  property:  indices,  together  with  the 
proofs  about  them,  do  not  influence  the  runtime  behavior  of  dependently-typed  programs  and  can  thus 
be  erased  prior  to  runtime.  This  is  the  same  property  that  holds  for  polymorphic  type  abstraction  and 
instantiation  in  System  F:  both  forms  can  be  erased. 

In  languages  with  a  tower  of  universes  we  might  say  that  a  generalization  of  this  property  holds: 
evaluating  a  term  of  universe  n  is  independent  from  all  terms  of  higher  universes  contained  in  it;  therefore 
these  can  be  erased  prior  to  evaluation.  This  is  the  intuition  behind  including  erasure  in  definitional 
equality  (as  done,  for  example,  in  [Miquel,  2001]);  doing  program  extraction  from  CIC  terms  [Paulin- 
Mohring,  1989,  Paulin-Mohring  and  Werner,  1993] ;  and  is  also  of  central  importance  in  the  optimizations 
that  Idris  performs  to  yield  efficient  executable  code  from  dependently-typed  programs  [Brady  et  ah,  2004, 
Brady,  2005], 

VeriML  does  not  support  such  a  phase  distinction,  as  the  indices  are  /HOL  terms  which  might  be  pat¬ 
tern  matched  against  and  therefore  influence  runtime.  Phase  distinction  holds  for  the  proof  objects  used 
to  discharge  proof  obligations  though;  this,  in  fact,  is  another  way  to  describe  the  proof  erasure  property 
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of  VeriML.  Yet,  as  the  obligations  are  discharged  during  static  evaluation,  the  indices  are  not  actually  pat¬ 
tern  matched  against:  indices  are  metavariables,  whose  instantiations  are  only  known  at  runtime,  but  the 
actual  proof  obligations  that  we  discharge  are  collapsed  versions,  and  so  the  metavariables  are  not  part  of 
them.  The  indices  are  only  used  to  bring  the  proofs  resulting  from  static  evaluation  into  the  appropriate 
context.  Since  the  proofs  themselves  can  be  erased,  it  makes  sense  to  also  allow  the  indices  to  be  erased. 

This  is  possible  by  adding  special  support  to  the  type  system,  in  order  to  mark  certain  dHOL  terms  as 
erasable.  The  type  system  then  checks  that  those  terms  are  not  pattern  matched  upon,  making  sure  that 
it  is  safe  to  erase  them  prior  to  runtime.  It  is  interesting  to  note  that  this  special  typing  support  can  take 
the  form  of  marking  dependent  dHOL  abstractions  or  tuples  as  static  where  the  associated  dHOL  terms 
are  only  allowed  to  be  used  during  stage-one  evaluation.  For  example,  the  type  of  append  could  be: 

append  :  (n  :s  Nat,  m  :s  Nat)  — >  vector  n  — >  vector  m—>{r:s  Nat)  x  vector  r  x(r  =  n  +  m)s 

This  reveals  a  relationship  betwen  staged  programming  and  dependently-typed  programming  (as  suggested 
for  example  in  Sheard  [2004])  which  warrants  further  investigation. 

Handling  impossible  branches.  We  mentioned  earlier  that  the  additional  typing  information  might 
allow  us  to  omit  certain  pattern  matching  cases,  yet  still  cover  all  possible  ones.  For  example,  the  code  of 
the  head  function  for  lists  is: 

head  :  vector  ( succ  n)  — >  vector  n 

head  /  =  match  /  with  cons  hd  tl  hd 

The  compiler  can  indeed  discover  that  the  omitted  nil  branch  is  impossible,  as  it  would  mean  that  the  false 
proposition  succ  n  =  0  is  provable  based  on  the  available  typing  information.  Thus  this  check  employs 
theorem  proving  as  well,  requiring  us  to  show  that  the  omitted  branches  lead  to  contradictions. 

We  need  an  additional  construct  in  order  to  support  such  impossible  branches  in  VeriML.  Its  typing 
rule  is  as  follows: 

T  b  t :  ([]  False) 

T;  A4;  T  b  absurd  t :  r 

This  construct  turns  a  closed  proof  of  the  contradiction  into  a  value  of  any  type.  It  can  be  used  in 
impossible  branches  in  order  to  return  a  term  of  the  required  type.  The  required  proof  can  be  handled  as 
above,  through  static  proof  expressions: 

head  /  =  match  /  with  cons  hd  tl  >-*■  hd 

|  nil  >— >  absurd  {{Auto}} 

The  semantics  of  the  construct  are  interesting:  no  operational  semantics  rule  is  added  at  all  for  the 
new  construct!  In  order  for  the  progress  theorem  to  continue  to  hold  we  must  make  sure  that  a  closed 
absurd  t  expression  will  never  be  encountered.  Equivalently,  we  must  make  sure  that  no  closed  dHOL 
proof  object  for  the  proposition  False  exists.  This  is  exactly  the  statement  of  soundness  for  dHOL.  We 
therefore  understand  that  the  addition  of  the  absurd  construct  requires  soundness  of  dHOL  to  hold;  in 
fact,  it  is  the  only  construct  we  have  presented  that  requires  so. 
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Chapter  8 

Prototype  implementation 


We  have  so  far  presented  the  VeriML  language  design  from  a  formal  standpoint.  In  this  chapter  we  will 
present  how  VeriML  can  be  practically  implemented.  Towards  that  effect  I  have  completed  a  prototype 
implementation  of  VeriML  that  includes  all  the  features  we  have  seen  so  far  as  well  as  a  number  of  other 
features  that  are  practically  essential,  such  as  a  type  inference  mechanism.  The  prototype  is  programmed 
in  the  OCaml  programming  language  [Leroy  et  ah,  2010]  and  consists  of  about  10k  lines  of  code.  It  is 
freely  available  from  http :  //www.  cs  .yale .  edu/homes/stampoulis/. 

8.1  Overview 

The  VeriML  implementation  can  be  understood  as  a  series  of  components  that  roughly  correspond  to 
the  phases  that  an  input  VeriML  expression  goes  through:  parsing;  syntactic  elaboration;  type  inferenc- 
ing;  type  checking;  and  evaluation.  We  give  an  example  of  these  phases  in  Figure  8.1.  Parsing  turns  the 
input  text  of  a  VeriML  expression  into  a  concrete  syntax  tree ;  syntactic  elaboration  performs  syntax-level 
transformations  such  as  expansion  of  syntactic  sugar  and  annotation  of  named  variables  with  their  corre¬ 
sponding  hybrid  deBruijn  variables,  yielding  an  abstract  syntax  tree.  Type  inferencing  attempts  to  fill  in 
missing  parts  of  VeriML  expressions  such  as  implicit  arguments  and  type  annotations  in  constructs  that 
need  them  (e.g.  (  T,  e  }  and  holmatch).  Type  checking  then  validates  the  completed  expressions  according 
to  the  VeriML  typing  rules.  This  is  a  redundant  phase  as  type  inferencing  works  according  to  the  same 
typing  rules;  yet  it  ensures  that  the  more  complicated  type  inferencing  mechanism  did  not  introduce  or 
admit  any  ill-typed  terms. 

The  last  phase  is  evaluation  of  VeriML  expressions  based  on  the  operational  semantics.  We  have  im¬ 
plemented  two  separate  evaluation  mechanisms  for  VeriML:  an  interpreter,  written  as  a  recursive  OCaml 
function  (from  VeriML  ASTs  to  VeriML  ASTs);  and  a  translator,  which  translates  well-typed  VeriML  ex¬ 
pressions  to  OCaml  expressions  (a  function  from  VeriML  ASTs  to  OCaml  ASTs).  The  resulting  OCaml 
expressions  can  then  be  treated  as  normal  OCaml  programs  and  compiled  using  the  normal  OCaml  com¬ 
piler.  We  will  only  cover  the  latter  approach  as  we  have  found  evaluation  through  translation  to  OCaml 
to  be  at  least  one  order  of  magnitude  more  efficient  than  direct  interpretation. 

Our  prototype  also  includes  an  implementation  of  the  dHOL  logic.  Since  terms  of  the  dHOL  logic 
are  part  of  the  VeriML  expressions,  the  above  computational  components  need  to  make  calls  to  the  corre¬ 
sponding  logical  components  -  for  example,  the  VeriML  expression  parser  calls  the  dHOL  parser  to  parse 
logical  terms.  Our  implementation  of  the  dHOL  logic  is  thus  structured  into  components  that  perform 
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Input  VeriML  text: 

fun  phi  T  tl  t2  =>  match  isEqual  tl  t2  with  . . . 


Parsing 

Concrete  syntax  tree: 

Aphi./lT./ltl./lt2.sumcase(isEqual _ 1 1  f  2,  ) 

Syntactic  elaboration 
Abstract  syntax  tree: 

Aphi :  _./lT  :  Atl :  _.Xt2  :  _.sumcase(isEqual _ Bx  B0,  •••,•••) 


|  Type  inference 

Fully-explicit  abstract  syntax  tree: 

Aphi :  ctx.X T  :  [50]  Type. Xtl :  [B^\Ba.Xt2  :  [B2]B0. 
sumcase(isEqual  B3  B2  Bx  B0,  ■■■,■■■) 

Type  checking 

Well-typed  abstract  syntax  tree: 
dphi :  ctx./ IT  :  [S0]  Type. Xtl :  [S1]S0./lt2  :  [B2]B0. 
sumcase(isEqual  B3  B2  Bl  B0,  ■■■,■■■) 


| Translation  to  OCaml 
Output  OCaml  AST: 

fun  (phi  :  Logic. ctx)  (T  tl  t2:  Logic. term)  => 
match  isEqual  phi  T  tl  t2  with  . . . 


Figure  8.1:  Components  of  the  VeriML  implementation 
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parsing,  syntactic  elaboration,  type  inferencing  and  type  checking  for  logical  terms,  following  the  struc¬ 
ture  of  the  computational  language  implementation.  Last,  the  translation  of  logical  terms  into  OCaml 
ASTs  is  done  by  reusing  the  dHOL  implementation.  The  resulting  OCaml  code  thus  needs  to  be  linked 
with  (part  of)  the  dHOL  implementation. 

In  the  rest,  we  will  describe  each  component  in  more  detail  and  also  present  further  features  of  the  proto¬ 
type. 

8.2  Logic  implementation 

The  core  of  our  implementation  of  dHOL  that  includes  parsing,  syntactic  elaboration  and  typing  consists 
of  about  1.5k  lines  of  code.  It  follows  the  presentation  of  the  logic  given  in  Section  4.2.  The  relevant  files 
in  our  prototype  are: 

syntax_trans_logic  .ml  Parsing  for  dHOL  terms 

logic_cst  .ml  Concrete  syntax  trees;  syntactic  elaboration  (CST  to  AST  con¬ 

version) 

logic_ast .  ml  Abstract  syntax  trees  and  syntactic  operations 

logic_core .  ml  Core  auxiliary  logic  operations 

logic_typing .  ml  dHOL  type  checking 

Concrete  syntax.  Parsing  is  implemented  through  Camlp4  grammar  extensions;  we  present  examples 
of  the  concrete  syntax  in  Table  8.1.  Our  parser  emits  concrete  syntax  trees:  these  are  values  of  a  datatype 
that  corresponds  to  dHOL  terms  at  a  level  close  to  the  user  input.  For  example,  concrete  syntax  trees 
use  named  variables,  representing  the  term  Ax  :  Nat.x  as  LLamC'x" ,  VarC'Nat"),  Var("x")).  Also 
they  allow  a  number  of  syntactic  conveniences,  such  as  being  able  to  refer  to  a  metavariable  V  without 
providing  an  explicit  substitution  a;  referring  to  both  normal  variables  v  and  meta-variables  V  without 
distinguishing  between  the  two;  and  also  maintaining  and  referring  to  an  “ambient  context”  denoted  as 
@  in  order  to  simplify  writing  contextual  terms  -  e.g.  in  order  to  write  \_<j),  x  :  Nat ]  x  =  x  as  @x  =  x 
when  the  ambient  context  has  already  been  established  as  <f>,  x  :  Nat.  We  will  see  more  details  of  this 
latter  feature  in  Subsection  8.3.1.  We  convert  concrete  syntax  trees  to  abstract  syntax  trees  which  follow 
the  dHOL  grammar  given  in  Section  4.2.  The  conversion  keeps  track  of  the  available  named  variables 
and  metavariables  at  each  point  and  chooses  the  right  kind  of  variable  (free  or  bound  normal  variable, 
free  or  bound  metavariable  or  constant  variable)  based  on  this  information.  We  chose  to  have  concrete 
syntax  trees  as  an  intermediate  representation  between  parsing  and  abstract  syntax,  so  that  managing  the 
information  about  the  variables  does  not  conflate  the  parsing  procedure. 

Abstract  syntax.  Abstract  syntax  trees  as  defined  in  our  implementation  follow  closely  the  grammar  of 
dHOL  given  in  Section  4.2.  We  depart  from  that  grammar  in  two  ways:  first,  by  allowing  holes  or  inferred 
terms  -  placeholders  for  terms  to  be  filled  in  by  type  inference,  described  in  detail  in  Subsection  8.2.1;  and 
second,  by  supporting  constant  schemata  c / a  instead  of  simple  constants  c  following  our  presentation  in 
Section  4.3. 

Furthermore,  we  allow  constant  definitions  in  order  to  abbreviate  terms  through  a  constant.  These 
constants  are  not  unfolded  to  their  corresponding  terms  under  any  circumstances  in  the  rest  of  the  logic 
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Concrete  syntax 

Abstract  syntax 

fun  x  :  t  =>  t’ 

A(t).t' 

forall  x  :  t,  t’ 

n  (t).t' 

-P 

A 

1 

-P 

n (t).t' 

tl  t2 

ti  ti 

tl  =  t2 

t\  =  ti 

X 

vL  or  bj  or  X / a  or  c /i 

x/  [<j] 

X  j  (j  or  c /  a 

id_phi,  tl,  t2,  ...,  tn 

ld( I L  ,  tn 

[phi ,  x  :  Nat] . x  =  x 

[<f>>  Nat ]  V\<t>\=V\ct>\ 

@x  =  X 

[<f>> Nat ]  V\J>\  =  V\J>\ wl 

>  =  (f>,  Nat 


Table  8.1:  Concrete  syntax  for  dHOL  terms 


implementation.  Unfolding  is  entirely  user-controlled,  through  the  unfold  axiom  that  reflects  the  equality 
between  a  constant  and  its  definition.  This  treatment  of  unfolding  follows  the  explicit  equality  approach 
that  we  presented  in  Section  7.1.  We  present  the  formal  details  of  this  extension  to  constant  signatures  £ 
in  Figure  8.2. 

Syntactic  operations.  The  syntactic  operations  presented  in  Section  4.2,  such  as  freshening  [■],  binding 
[•J  and  substitution  application  •  •  a  are  part  of  the  logic  implementation,  as  functions  that  operate  on 
abstract  syntax  trees.  These  operations  are  defined  over  various  datatypes  -  terms,  substitutions,  contexts, 
etc.  Furthermore,  other  kinds  of  variables  such  as  metavariables,  context  variables  and  even  computa¬ 
tional  variables  are  represented  in  the  implementation  through  hybrid  deBruijn  variables  as  well,  as  this 
representation  makes  for  code  that  is  easier  to  work  with  than  deBruijn  indices.  In  order  to  reuse  the  code 
of  these  basic  operations,  we  have  implemented  them  as  higher-order  functions.  They  expect  a  traversal 
function  over  the  specific  datatype  that  they  work  on  which  keeps  track  of  the  free  and  bound  variables 
at  each  subterm.  These  generic  operations  are  defined  in  the  binding .  ml  file  of  the  prototype  implemen¬ 
tation. 

Type  checking.  The  typing  rules  for  dHOL  are  all  syntax-directed :  every  dHOL  term  constructor  cor¬ 
responds  exactly  to  a  single  typing  rule.  Thus  we  do  not  need  a  separate  formulation  of  algorithmic  typing 
rules;  the  typing  rules  given  already  suggest  a  simple  type  checking  algorithm  for  dHOL.  This  simplicity 
is  indeed  reflected  in  our  implementation:  the  main  procedure  that  implements  type  checking  of  dHOL 
abstract  syntax  trees  is  just  under  300  lines  of  OCaml  code.  As  a  side-effect,  the  type  checker  fills  in  the 
typing  annotations  that  pattern  matching  requires  and  thus  yields  annotated  dHOL  terms,  as  presented 
in  Section  5.1.  For  example,  the  Il-type  former  is  annoted  with  the  sort  of  the  domain,  yielding  terms  of 
the  form  IIs(f  j.th 

An  important  function  that  type  checking  relies  on  is  lterm_equal  which  compares  two  logical  terms 
up  to  definitional  equality,  which  in  the  case  of  dHOL  is  simply  syntactic  equality.  It  is  used  often  during 
type  checking  to  check  whether  a  type  matches  an  expected  one  -  e.g.  we  use  it  in  the  implementation 
of  IIElim  rule  for  tx  t2,  where  tl  :  I 1(f). L  in  order  to  check  whether  the  type  of  t2  matches  the  domain 
of  the  function  type  t .  This  equality  checking  function  is  one  of  the  main  parts  of  the  implementation 
that  would  require  changes  in  order  to  support  a  fixed  conversion  rule  in  the  logic,  yielding  dHOLc;  as 
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Syntax: 


( Signature )  E  ::=  •  •  •  |  E,  c  :  [<b]  t'  =  [<b]  t 
( Logical  terms )  t  ::=•••  |  unfold  c/a 


b  E  wf 


h  E  wf  •  bs  [$]  sf  Type  •;  •  bE  [$]  t:[$]f  (c  :  _)  ^  E 

- - - SigConstDef 

b  E,  c  :  [<b]  t  =  [<b]  t  wf 


<b  bs  t :  t' 


the  rule  ConstSChema  is  replaced  by: 

c  :  [^b]  f  €  E  or  c  :  [3b]  t/  =  _eE  \b;  $  b  a  :  <fb 

- - - CONSTSCHEMA 

'b;  $  by.  c/ a  :  t  •  a 

c  :  [$']  t'  =  [$']  £  €  E  'b;  $  b  o' : 

- EqUnfold 

'b;  $  b  unfold  c/a  :  c/a  =  t  ■  a 


Figure  8.2:  Extension  to  bHOL  signatures  with  definitions:  Syntax  and  typing 

mentioned  in  Section  7.1,  these  changes  become  instead  part  of  the  standard  rewriter  and  equality  checker 
programmed  in  VeriML  and  do  not  need  to  be  trusted. 

8.2.1  Type  inference  for  logical  terms 

One  of  the  important  additions  in  our  implementation  of  dHOL  compared  to  its  formal  description  is 
allowing  terms  that  include  holes  or  inference  variables  -  missing  subterms  that  are  filled  in  based  on  infor¬ 
mation  from  the  context.  This  is  an  essential  practical  feature  for  writing  logical  terms,  as  the  typed  nature 
of  dHOL  results  in  many  redundant  occurrences  of  simple-to-infer  terms.  For  example,  the  constructor 
for  logical  conjunction  has  the  type: 

andl :  VP,  Q  :  Prop,  P  — »  Q  — *  P  A  Q 

The  two  first  arguments  are  redundant,  since  the  type  of  the  second  two  arguments  (the  proof  objects 
proving  P  and  Q)  uniquely  determine  what  the  propositions  P  and  Q  are.  Given  proofs  n1  and  n2,  we 
can  use  inference  variables  denoted  as  ?  to  use  the  above  constructor: 

andl  ?  ?  ri-y  7t2 

Another  example  is  using  the  elimination  principle  for  natural  numbers  of  type: 

elimNat :  [P  :  Type]  T  — >  (Nat  —*■  T  — ►  T)  — >  Nat  —*■  T 
We  can  use  this  to  write  the  addition  function,  as  follows: 

plus  =  Ax  :?.dy  :?. elimNat /[?]  y  (Ap  :?.dr  P.succ  r)  x 
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or  more  succinctly,  using  syntactic  sugar  for  functions  and  use  of  constants,  as: 

plus  =  Ax.Ay.elimNat  y  ( Ap.Ar.succ  r )  % 


Intuitively,  we  can  view  inference  variables  as  unknowns  for  whom  typing  generates  a  set  of  con¬ 
straints;  we  instantiate  the  inference  variables  so  that  the  constraints  are  satisfied,  if  possible.  In  the  case  of 
dHOL,  the  constraints  are  requirements  that  the  inference  variables  be  syntactically  equal  to  some  other 
terms.  For  example  consider  the  following  typing  derivation: 


_ ^ _  ($.  ?i)-*=?i 

\F;  $,  x  :?j  b  :  t  —*■  t'  \F;  $,  %  :?t  b  x  :  t 
'F;  $,  x  :?j  h  t1  x  :  t' 

'F;  $  h  (Ax  iPj.tj  x)  :?j  — *■  t' 


VAR 


IIElim 


IIlNTRO 


From  the  application  of  the  Var  typing  rule  the  constraint  ?x  =  t  follows  directly.  More  complicated 
constraints  are  also  common,  if  we  take  into  account  the  fact  that  our  typing  rules  work  involve  operations 
such  as  freshening,  binding  and  also  application  of  substitutions.  For  example,  in  the  following  typing 
derivation  we  use  a  non-identity  substitution  with  a  metavariable: 


(Ff:[$/]?1)G'F 


MetaVar 


iF;<Fh  H/[X,Y]3v(Xla,Ylb) 
f  :(X  =  Y)  ^  (Y  =  X)\-  f  H  /[X  ,Y]  :Y  =  X 


IIElim 


where 


'F  =  <f> :  ctx,  X  :  [<^>]  Nat,  Y  :  [<^>]  Nat,  H  :  \a  :  Nat,  b  :  Nat ]  ?j 
resulting  in  the  following  constraint: 


h-(X/a,  Y/b)  =  (X  =  Y) 

which  can  be  solved  for 


h=(a  =  b) 

These  equality  constraints  are  not  explicit  in  our  formulation  of  the  typing  rules,  yet  an  alternative 
presentation  of  the  same  typing  rules  with  explicit  constraints  is  possible,  following  the  approach  of  Pot- 
tier  and  Remy  [2005],  Intuitively,  the  main  idea  is  to  replace  cases  where  a  type  of  a  specific  form  is 
expected  either  in  the  premises  or  consequences  of  typing  rules,  with  an  appropriate  constraint.  The 
constraints  might  introduce  further  inference  variables.  For  example,  the  typing  rule  IIElim  can  be  for¬ 
mulated  instead  as: 

\F;  $  b  tj  :?j  \F;  $  b  t7  :?2 

?!  =n(?3).?4  ?2=?3  ?r  =  r?4l-(«**,*2)  T 

- IIElim-Infer 

T;  $ht1t2:?r 

We  can  view  this  as  replacing  the  variables  we  use  at  the  meta-level  (the  variables  that  we  implicitly 
quantify  over,  used  for  writing  down  the  typing  rules  as  mathematical  definitions),  with  the  concrete 
notion  of  inference  variables.  We  have  implemented  a  modified  type  checking  algorithm  in  the  file 
logic_typinf  .ml  which  works  using  rules  of  this  form. 
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The  presence  of  explicit  substitutions  as  well  as  the  fact  that  the  constraints  might  equate  inference 
variables  with  terms  that  contain  further  inference  variables  renders  the  problem  of  solving  these  con¬ 
straints  equivalent  to  higher-order  unification.  Thus,  solving  the  constraint  set  generated  by  typing  deriva¬ 
tions  in  the  general  case  is  undecidable.  Our  implementation  does  not  handle  the  general  case,  aiming  to 
solve  the  most  frequent  cases  efficiently.  Towards  that  effect,  it  solves  constraints  eagerly ,  as  soon  as  they 
are  generated,  rather  than  running  typing  to  completion  and  having  a  post-hoc  phase  of  constraint  solving. 

Implementation  details.  The  key  point  of  our  implementation  that  enables  support  for  inference  vari¬ 
ables  and  the  type  inferencing  algorithm  is  having  the  procedure  lterm_equal  that  checks  equality  be¬ 
tween  terms  be  a  unification  procedure  instead  of  a  simple  syntactic  comparison.  When  an  uninstantiated 
inference  variable  is  compared  to  a  term,  the  variable  is  instantiated  accordingly  so  that  the  comparison  is 
successful.  The  type  inference  algorithm  thus  uses  lterm_equal  in  order  to  generate  and  solve  constraints 
simultaneously  as  mentioned  above. 

We  implement  inference  variables  as  mutable  references  of  option  type;  they  are  initially  empty  and 
get  assigned  to  a  term  when  instantiated.  Syntactic  operations  such  as  freshening,  binding  and  substitution 
application  cannot  be  applied  to  uninstantiated  variables.  Instead  we  record  them  into  a  suspension  -  a 
function  gathering  their  effects  so  that  they  get  applied  once  the  inference  variable  is  instantiated.  Thus 
we  represent  inference  variables  as  a  pair: 

(?„,/) 

where  }n  is  understood  as  the  mutable  reference  part  and  f  as  the  composition  of  the  applied  syntactic 
operations.  Thus  the  constraint  •  (X /a,  Y / b)  =  (X  =  Y)  given  as  an  example  above,  will  instead  by 
represented  and  solved  by  an  equality  checking  call  of  the  form: 

lterm_equal  (?1;  fi)  {X  =  Y) 

where  the  suspension  /  is  defined  as  f  =  —  -{X /a,  Y /b).  Different  occurrences  of  the  same  inference  vari¬ 
able  -  arising,  for  example,  from  an  application  like  t]  ?2  where  t1  :  II (t).t'  and  t'  has  multiple  occurrences 
of  the  bound  variable  bQ  -  share  the  reference  part  but  might  have  a  different  suspension,  corresponding 
to  the  point  that  they  are  used.  Because  of  the  use  of  mutable  references,  all  occurrences  of  the  same 
inference  variable  get  instantiated  at  the  same  time. 

The  main  subtlety  of  instantiating  inference  variables  is  exactly  the  presence  of  suspensions.  In  the 
case  where  we  need  to  unify  an  inference  variable  with  a  term 

(?»>/)  =  * 

we  cannot  simply  set  ?„  =  t:  even  if  we  ignore  the  suspension  /,  further  uses  of  the  same  inference  variable 
with  a  different  suspension  f  will  not  have  the  intended  value.  The  reason  is  that  t  is  the  result  of  some 
applications  of  syntactic  operations  as  well: 

(?»>/)  =  *  where  t  =  f(t") 

(?„,/')  =  t'  where  *'  =  /'(*") 

Instead  of  unifying  ?n  with  t,  we  should  unify  it  with  t";  applying  the  suspensions  as  first  intended  will 
result  in  the  right  value  in  both  cases.  In  order  to  do  this,  we  also  maintain  an  inverse  suspension  fi~l  as 
part  of  our  representation  of  inference  variables,  leading  to  triples  of  the  form: 

( -1) 
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where  f  o  f~x  =  id.  Instantiating  ?H  with  yields  the  desired  result  in  both  occurrences  of  the 

variable. 

Keeping  in  mind  that  f  is  a  composition  of  syntactic  operations,  e.g.  f  =  [— ]  o  (—  •  a),  we  maintain 
the  inverse  suspension  by  viewing  it  as  a  composition  of  the  inverse  syntactic  operations,  e.g.  /-1  = 
(—  •  <J~X)  ■  [— 1  .  In  the  case  of  freshening  and  binding,  these  inverse  operations  are  trivial  since  [■]  =  [-J  1 . 
Yet  in  the  case  of  applying  a  substitution  a,  the  case  that  an  inverse  substitution  a~x  exists  is  but  a 
special  case  -  essentially,  when  cr  is  a  renaming  of  free  variables  -  so  we  cannot  always  set  f~l  =  (—  • 
In  the  general  case,  a  might  instantiate  variables  with  specific  terms.  The  inverse  operation  is  then 
the  application  of  a  generalized  notion  of  substitutions  aG  where  arbitrary  terms  -  not  only  variables 
-  can  be  substituted  for  other  terms.  In  our  implementation,  unification  does  not  handle  such  cases  in 
full  generality.  We  only  handle  the  case  where  the  applied  substitutions  are  renamings  between  normal 
variables  and  meta-variables.  This  case  is  especially  useful  for  implementing  static  proof  expressions  as 
presented  in  Section  7.2,  which  yield  constraints  of  the  form: 

V(*/«,  Y/b)  =  (X  =  Y ) 

as  seen  above,  where  X  and  Y  are  metavariables  and  a  and  b  are  normal  variables.  In  this  case,  our 
representation  of  inference  variables  yields: 

(?i,/  =  (-.u),/-1  =  (-.u-1))  =  (Y  =  F) 

with  a  =  (X /a,  Y / b )  and  a~x  =  (a/X,  b /Y),  which  leads  to 

}i=f~\X  =  Y)  =  (a  =  b) 

as  desired. 

The  implementation  of  these  inference  variables  forms  the  main  challenge  in  supporting  type  infer¬ 
ence  for  logical  terms.  The  actual  type  inference  algorithm  mimics  the  original  type  checking  algorithm 
closely.  The  main  departure  is  that  it  exclusively  relies  on  the  equality  checking/unification  procedure 
lterm_equal  to  impose  constraints  on  types,  even  in  cases  where  the  original  type  checker  uses  pattern 
matching  on  the  return  type.  An  example  is  checking  function  application,  where  instead  of  code  such  as: 

App(tl,  t2)  I ->  let  tl_t  =  type_of  tl  in 
let  t2_t  =  type_of  t2  in 
match  tl_t  with 

Pi(var,  t,  t’)  ->  lterm_equal  t  t2_t 

we  have: 

App(tl,  t2)  | ->  let  tl_t  =  type_of  tl  in 
let  t2_t  =  type_of  t2  in 
let  t  =  new_inf er_var  ()  in 
let  t*  =  new_inf er_var  ()  in 
let  tl_expected  =  Pi(var,  t,  t’)  in 
lterm_equal  tl_t  tl_expected  &&  lterm_equal  t  t2_t 

Essentially  this  corresponds  to  using  typing  rules  similar  to  IIElim-Infer,  as  described  above.  Our  type 
inference  algorithm  also  supports  bi-directional  type  checking:  it  accepts  an  extra  argument  representing 
the  expected  type  of  the  current  term,  and  instantiates  this  argument  accordingly  during  recursive  calls. 
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The  two  directions  of  bi-directional  type  checking,  synthesis  (determining  the  type  of  an  expression)  and 
analysis  (checking  an  expression  against  a  type),  correspond  to  the  case  where  the  expected  type  is  simply 
an  uninstantiated  inference  variable,  and  the  case  where  it  is  at  least  partially  instantiated,  respectively. 
This  feature  is  especially  useful  when  the  expected  type  of  a  term  is  known  beforehand,  as  type-checking 
its  subterms  is  informed  from  the  extra  knowledge  and  further  typing  constraints  become  solvable. 


8.2.2  Inductive  definitions 


Our  logic  implementation  supports  inductive  definitions  in  order  to  allow  users  to  define  and  reason 
about  types  such  as  natural  numbers,  lists,  etc.  Also,  it  allows  inductive  definitions  of  logical  predicates, 
which  are  used  to  define  logical  connectives  such  as  conjunction  and  disjunction,  and  predicates  between 
inductive  types,  such  as  the  less-than-or-equal  relation  between  natural  numbers.  Each  inductive  definition 
generates  a  number  of  constants  added  to  the  signature  context  S,  including  constants  for  constructors  and 
elimination  and  induction  principles.  Support  for  inductive  types  is  necessary  so  as  to  prescribe  a  ‘safe’ 
set  of  axioms  that  preserve  logical  soundness,  as  arbitrary  additions  to  the  constant  signature  can  lead  to 
an  inconsistent  axiom  set.  It  is  also  necessary  from  a  practical  standpoint  as  it  simplifies  user  definitions 
significantly  because  of  the  automatic  generation  of  induction  and  elimination  principles.  Our  support 
follows  the  approach  of  inductive  definitions  in  CIC  [Paulin-Mohring,  1993]  and  Martin-Lof  type  theory 
[Dybjer,  1991],  adapted  to  the  dHOL  logic. 

Let  us  proceed  to  give  some  examples  of  inductive  definitions.  First,  the  type  of  natural  numbers  is 
defined  as: 


InductiveAbi  :  Type  := 
zero  :  Nat 
\  succ  :  Nat  — *  Nat 

This  generates  the  following  set  of  constants: 


Nat 

zero 

succ 

elimNat 

elimNatZero 

elimNatSucc 

indNat 


Type 

Nat 

Nat  —>■  Nat 

[t  :  Type]  t  — *■  (Nat  — *■  t  —*  t)  — *  Nat  — *  t 
[t  :  Type]  V fjs, elimNat  fz  fs  zero  =  fz 

[ t  :  Type]  VfJs p ,  elimNat  fz  fs  (succ  p)  =  fsp  (elimNat  fzfsp ) 
VP  :  Nat  —*■  Prop.P  zero  —*■  (V n,P  n  — *■  P  (succ  n))  — >  V n,P  n 


The  elimination  principle  elimNat  is  used  to  define  total  functions  over  natural  numbers  through  primi¬ 
tive  recursion;  the  axioms  elimNatZero  and  elimNatSucc  correspond  to  the  main  computation  steps  asso¬ 
ciated  with  it.  They  correspond  to  one  step  of  '-reduction,  similar  to  how  the  beta  axiom  corresponds  to 
one  step  of  /3-reduction.  An  example  of  such  a  function  definition  is  addition: 


plus  =  Xx.Xy .elimNat y  (Xp.Xr. succ  r)  x 


Through  the  rewriting  axioms  we  can  prove: 

plus  zero  y  =  y 

plus  (succ  x)  y  =  succ(plus  x  y) 

The  induction  principle  indNat  is  the  standard  formulation  of  natural  number  induction  in  higher-order 
logic.  Lists  are  defined  as  follows,  with  t  as  a  type  parameter. 
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Inductive  List  :  [t :  Type ]  Type  := 
nil  :  List 

;  cons  :  t  — >  Tzst  — >  Tzst 

We  also  use  inductive  definitions  to  define  connectives  and  predicates  at  the  level  of  propositions.  For 
example,  we  define  logical  disjunction  V  as: 

Inductive  or  :  [A  :  Prop,  B  :  Prop]  Prop  := 
orlntroL  :  A  — *  or/\A,  B] 

\  orlntroR  :  B-+or/[A,B] 

generating  the  following  set  of  constants: 

or  :  [A:  Prop,  B  :  Prop]  Prop 

orlntroL  :  [A  :  Prop,  B  :  Prop]  A  — >  or/ [A,  B] 
orlntroR  :  [A  :  Prop,  B  :  Prop]  B  —*■  or/ [A,  B] 
indOr  :  [A  :  Prop,  B  :  Prop]  VP  :  Prop, 

(A P) —*  (B  P) (or/\A,B]  — ►  P) 

We  have  defined  the  two  arguments  to  or  as  parameters,  instead  of  defining  or  as  having  a  kind  Prop  — * 
Prop  — >  Prop,  as  this  leads  to  the  above  induction  principle  which  is  simpler  to  use. 

An  example  of  an  inductively-defined  predicate  is  less-than-or-equal  for  natural  numbers: 

Inductive/e  :  Nat  —*■ Nat  — ►  Prop  := 
leBase  :  dn,lenn 
leStep  :  V nm ,/e  n  m  — *■  le  n  ( succ  m) 

generating  the  induction  principle: 

indLe  :  VP  :  Nat  — >  Nat  —*■  Prop, 

(Vn,P  n  n)—* 

(dnm,le  nm-^Pnm^Pn  ( succ  m ))  —» 

(dnm,len  m  —*■  P  n  m ) 

The  types  of  constructors  for  inductive  definitions  need  to  obey  the  strict  positivity  condition  [Paulin- 
Mohring,  1993]  with  respect  to  uses  of  the  inductive  type  under  definition.  This  is  done  to  maintain 
logical  soundness,  which  is  jeopardized  when  arbitrary  recursive  definitions  such  as  the  following  are 
allowed: 

Inductive!)  :  Type  :=  mkD  :  (!)—»!))—>•!) 

This  definition  in  combination  with  the  generated  elimination  principle  allows  us  to  define  non-terminating 
functions  over  the  type  D,  which  renders  the  standard  model  used  for  the  semantics  of  dHOL  unusable. 
In  order  to  check  the  positivity  condition,  we  extend  the  dHOL  type  system  to  include  support  for 
positivity  types,  following  the  approach  of  Abel  [2010],  instead  of  the  traditional  implementation  using 
syntactic  checks  used  in  Coq  [Barras  et  ah,  2012]  and  other  proof  assistants.  This  results  in  a  simple  im¬ 
plementation  that  can  directly  account  for  traditionally  tricky  definitions,  such  as  nested  inductive  types. 
The  elimination  principles  are  generated  through  standard  techniques. 

We  give  a  formal  sketch  of  the  required  extensions  for  positivity  types  to  dHOL  typing  in  Figure  8.3. 
The  main  idea  is  that  contexts  $  carry  information  about  whether  a  variable  must  occur  positively  (de¬ 
noted  as  t+ )  or  not.  We  change  the  type  judgement  so  that  it  includes  the  polarity  of  the  current  position: 
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Syntax 


( Contexts )  $  ::=  •  •  •  |  <P,  t+ 

( Polarities )  p  ::=  —  |  ++  |  + 


'P;  <P  h  f.P  t' 


$.L  =  t+  p  +  -  <S>.L=t 

- — - VARPOS  - 

\P;  $  h  vL  \P  t  \P;  $  h  vL  \P  t 

'P;  <P  b  tx  -A  s  'P;  <P,  tx  h  [f2l|$|  :p  s'  { s,s',s")eK 

'P;  U(t{).t2:P  s" 


VarAny 


IIType 


'P;$ht1:  5  'P;  h  h  ft2l|$|  :  t'  'P;  <P  h  Ilfo).  [t' \ 


I  |$|+i 


—  / 
:  s 


'p;  ^^Kh)-h:p n(ti). 


IIlNTRO 


’P;$ht1:*’n(t).t/  'P;$ht2:  t  'P .i  =  T  T  =  \$']t'  'P;  $  h  a  •*  $' 

- IIElim  _ !: _ _ _ 1 _ 


'P;  $  I"  h  h  -P  \ t']  |$|  •  Hr»  h) 


'P;  XJa  -P  t'-a 


\P;  $  h  <r  :++  <§>'  \P;  $  h  t  :++  t'  ■  a 

- - — - - SubstPosVarPos 

'P;  $h(o-,  t):++  ($',  t'+) 

\P;  $  h  a  :++  \P;  $  h  t  t'  ■  a 

- SubstAnyVarPos 

'P;  $h(<7,  t):++  ($',  t') 

\P;  $  h  a  :+  \P;  $  h  t  :++  t'  ■  a 

- - - — - SubstPosVarAny 

'P;  $h(<r,  t):+  ($',  tl+ ) 

'P;  $  h  a  -P  $'  t-St'-a 

- — - SubstAnyVarAny 

t):P  ($',  t') 


+  I  —  H — h 
H — h  |  =  — 

-I  =  - 


Figure  8.3:  Extension  /.HOL  with  positivity  types 


MetaVar 
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the  positive  polarity  +  for  positive  positions;  the  strictly  positive  polarity  ++;  and  the  negative  polarity 
—  where  only  normal  unrestricted  variables  can  be  used.  We  demote  polarities  when  in  the  domain  of  a 
function  type;  in  this  way  we  allow  constructors  with  type  (Nat  —*■  Ord)  — >  Ord,  where  Ord  occurs  pos¬ 
itively  (the  limit  constructor  of  Brouwer  ordinals);  but  we  disallow  constructors  such  as  (D  —*■  D)  —*■  D, 
as  the  leftmost  occurrence  of  D  is  in  a  negative  position.  We  take  polarities  into  account  when  checking 
substitutions  used  with  metavariables.  Thus  if  we  know  that  a  certain  parametric  type  (e.g.  lists)  uses  its 
parameter  strictly  positively,  we  can  instantiate  the  parameter  with  a  positive  variable.  This  is  used  for 
defining  rose  trees  -  trees  where  each  node  has  an  arbitrary  number  of  children: 


Inductive  List  :  [t :  Type+\  Type  := 
nil  :  List 

I  cons  :  t  — *  List  —*■  List 


I  nducti ye  Rose  :  [t :  Type+]  Type  := 
node  :  List /  [Rose] Rose 


Using  the  new  judgements,  inductive  definitions  can  be  simply  checked  as  follows  (we  use  named 
variables  for  presentation  purposes): 

•  b[$]£:s  t  =  Uxargs:targ].s'  s'  G  (Prop,  Type) 

•;  <b,  name  :  t+  b  t-  :+  s'  t;  =  Ilx1  :  t1  .name  t2 

_ _ * _ * _ i _ i 

h  (Inductive  name  :  [<£>]  t  :=  cnamet  :  £•)  wf 

That  is,  the  inductive  definition  must  have  an  appropriate  arity  at  one  of  the  allowed  sorts  for  definitions, 
the  positivity  condition  must  hold  for  the  occurrences  of  the  new  type  in  each  constructor,  and  each 
constructor  must  yield  an  inhabitant  of  the  new  type. 


8.3  Computational  language  implementation 

The  implementation  of  the  VeriML  computational  language  follows  a  similar  approach  to  the  implemen¬ 
tation  of  dHOL  with  similar  components  (parsing,  syntactic  elaboration,  typing  and  type  inference). 
Calls  to  the  relevant  dHOL  functions  are  done  at  every  stage  in  order  to  handle  logical  terms  appearing 
inside  computational  expressions.  Our  implementation  supports  all  the  constructs  presented  in  Chap¬ 
ter  6,  including  a  pattern  matching  construct  that  combines  all  the  features  presented  in  Section  6.2.  It 
also  includes  further  constructs  not  covered  in  the  formal  definition,  such  as  let  and  letrec  constructs  for 
(mutually  recursive)  definitions,  base  types  such  as  integers,  booleans  and  strings,  mutable  arrays,  generic 
hasing  and  printing  functions  and  monadic-do  notation  for  the  option  type.  Last  it  includes  support  for 
subtyping  based  on  context  subsumption  for  contextual  types  -  for  example,  a  type  such  as  list  ([<!>]  t)  is 
a  subtype  of  list  ([T,  %  :  t’]  t).  The  support  for  these  features  follows  standard  practice.  Here  we  will 
cover  the  surface  syntax  extensions  handled  by  syntactic  elaboration  and  also  aspects  of  the  evaluation  of 
VeriML  expressions  through  translation  to  OCaml. 

8.3.1  Surface  syntax  extensions 

The  surface  syntax  for  the  VeriML  computational  language  supports  a  number  of  conveniences  to  the 
programmers.  The  most  important  of  these  are  simplified  syntax  for  contextual  terms  and  surface  syntax 
for  tactic  application.  Other  conveniences  include  abbreviated  forms  of  the  constructs  that  make  use 
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of  inference  variables  in  their  expanded  form  -  for  example,  eliding  the  return  type  in  dependent  tuples 
( e  ) (X-.K)xt' 

Delphin-style  syntax  for  contextual  terms.  The  simplified  syntax  for  contextual  terms  is  based  on  the 
aforementioned  notion  of  an  ambient  contexts,  denoted  as  @  in  the  surface  syntax  of  our  implementation. 
We  denote  it  here  as  T@  for  presentation  purposes.  The  main  idea  is  to  use  the  ambient  context  instead  of 
explicitly  specifying  the  context  part  of  contextual  terms  [T]  t,  leading  to  contextual  terms  of  the  form 
@t  (denoting  [T@]  t).  Uses  of  metavariables  such  as  X /a  are  also  simplified,  by  taking  a  to  be  the  identity 
substitution  for  the  ambient  context  (more  precisely,  the  prefix  of  the  identity  substitution  id#  C  id§@ 
when  X  :  [<L]  t'  with  U  C  $@).  Furthermore,  we  include  constructs  to  manage  the  ambient  context:  a 
way  to  introduce  a  new  variable,  vx  :  t  in  e,  which  changes  the  ambient  context  to  =  T@,  %  :  t  inside  e. 
Also,  we  have  a  way  to  reset  the  ambient  context  and  specify  it  explicitly,  denoted  as  let  @  =  Tine.  Some 
existing  constructs,  such  as  abstraction  over  contexts  XS  :  ctx.e  also  update  the  ambient  context  so  as  to 
include  the  newly-introduced  context  variable:  =  T@,  <j>.  Based  on  these,  we  can  write  the  universal 

quantification  branch  of  the  tautology  prover  as: 

tautology  : 

tautology  = 

@Vx:Nat,Q  do  (pf’ ) «—  vx  :  Nat  in  tautology  @  @Q; 

return  (  @Xy  :  Nat.pf’/\id@,y]  } 

The  syntax  thus  supported  is  close  to  the  informal  syntax  we  used  in  Section  2.3.  Though  it  is  a  simple 
implementation  change  to  completely  eliminate  mentioning  the  ambient  context,  we  have  maintained  it 
in  order  to  make  the  distinction  between  contextual  terms  of  dHOL  and  computational  expressions  of 
VeriML  more  evident. 

The  idea  of  having  an  ambient  context  and  of  the  fresh  variable  introduction  construct  vx  :  t  in  e 
comes  from  the  Delphin  programming  language  [Poswolsky,  2009].  Delphin  is  a  similar  language  to 
VeriML,  working  over  terms  of  the  LF  framework  instead  of  dHOL;  also,  it  does  not  include  an  explicit 
notion  of  contextual  terms,  supporting  instead  only  terms  inhabiting  the  ambient  context  as  well  as  the 
constructs  to  manipulate  it.  Our  implementation  establishes  that  these  constructs  can  be  seen  as  syntac¬ 
tic  sugar  that  gets  expanded  into  full  contextual  terms  of  contextual  modal  type  theory  [Nanevski  et  al., 
2008b],  suggesting  a  syntax-directed  translation  from  Delphin  expressions  into  expressions  over  contex¬ 
tual  terms.  Instead  of  reasoning  explicitly  about  contextual  terms  as  we  do  in  our  metatheory,  Delphin 
manages  and  reasons  about  the  ambient  context  directly  at  the  level  of  its  type  system  and  operational 
semantics.  This  complicates  the  formulation  of  the  type  system  and  semantics  significantly,  as  well  as 
the  needed  metatheoretic  proofs.  Furthermore,  the  syntax-directed  translation  we  suggest  elucidates  the 
relationship  between  Delphin  and  Beluga  [Pientka  and  Dunfield,  2008],  a  language  for  manipulating  LF 
terms  based  on  contextual  terms,  similar  to  VeriML. 

Syntax  for  static  proof  expressions.  Our  implementation  supports  turning  normal  proof  expressions 
e  :  ([T]  P )  into  statically-evaluated  proof  expressions  as  presented  in  Section  7.2  with  a  simple  annotation 
{{ e }} .  Note  that  this  is  not  the  staging  construct,  as  we  assume  that  e  might  be  typed  under  an  arbitrary 
T  context  containing  extension  variables  instantiated  at  runtime.  This  construct  turns  e  into  a  closed 
expression  es  that  does  not  include  any  extension  variables,  following  the  ideas  in  Section  5.2;  it  then  uses 


(<f> :  ctx)  — *■  ( P  :  @Prop )  — *■  option  (@P) 
Xd>  :  ctx.XP  :  @Prop. holmatch  @P  with 
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the  staging  construct  {e5  }statjc  to  evaluate  the  closed  expression;  and  then  performs  the  needed  substitution 
of  variables  to  metavariables  in  order  to  bring  the  result  of  the  static  evaluation  into  the  expected  T  context 
with  the  right  type.  A  sketch  of  this  transformation  is: 

*;  S  r|s[atiCHM}:([$]P) 

«s £  rl»«c Het  (x  >  =  fcU in  < [*]*/» > :  (Wp) 

The  actual  implementation  of  this  construct  is  a  combination  of  syntactic  elements  -  most  impor¬ 
tantly,  manipulation  of  the  ambient  context  -  and  type  inference.  Let  us  first  present  an  example  of  how 
this  construct  is  used  and  expanded,  arising  from  the  plusRewriterl  example  seen  in  Section  7.2.  Consider 
the  following  code  fragment: 


plusRewriterl  = 

Xcf> :  ctx. XT  :  @Type.Xt  :  @T.holmatch  @t  with 
@x  +y  <->  let  (  y' ,  H' :  @y  =  y'  )  =  •  •  •  in 

let  (  t',  H"  :  @x  +y  —  t'  )  =  •  •  •  in 
(  t' ,  {{requireEqual  @@?j  @?2@?3}}  :  ( @x  +y  =  t ')  } 

where  requireEqual  has  type: 

requireEqual  :  (<f> :  ctx )  — >  (T  :  @Type)  —*  (t1;  t2  :  @T)  — >  ( @t1  =  t2) 
At  the  point  where  requireEqual  is  called,  the  extension  context  is: 


VF  =  <f> :  ctx,  T  :  @Type,  t,x,y,y' :  @Nat,  H'  :@y  =  y' ,  t' :  @Nat,  H"  :@x  +  y'  =  t' 


Based  on  this,  syntactic  elaboration  will  determine  the  A  construct  used  in  the  expansion  of  {{•••}}  as 
(using  Ao  signify  normal  variables  and  differentiate  them  from  the  metavariables  they  correspond  to): 


$'=r  :?r,  ?:? 


x$x,y$y. 


y :?  / 

/  -y 


H" :? 


■  f  > 


H" 


and  the  substitution  a  as: 


o  =  ’T/\ld</>\>  t/iid^],  x/lidf],  y/\id (/)],  y'/[id^\,  H' / [id ^\,  t'/[id^\,  H" /[id ^ 
The  expansion  then  is: 


{{requireEqual  @@?j  @?9  @?3}} 
let(S:[$/]?3)  = 

let@=  in  {requireEqual  @@?!  @?2  @?3}static 
in 

([^S /a) 


From  type  inference,  we  get  that: 


?3  •  a  =  %  +y  =  t' 
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From  this,  we  get  that  ?3  EE  x  +  y  =  t  .  The  rest  of  the  inference  variables  are  similarly  determined. 

The  implementation  thus  works  as  follows.  First,  we  transform  e  into  a  closed  expression  es  by  relying 
on  the  ambient  context  mechanism.  We  expect  all  contextual  terms  inside  e  to  refer  only  to  the  ambient 
context.  We  change  the  ambient  context  to  the  &  context,  as  determined  syntactically  by  introductions 
of  metavariables  and  normal  variables  through  the  vx  in  e  construct.  Normal  variables  from  <l>'  shadow 
meta-variables  leading  to  a  closed  expression.  The  exact  types  in  T7  are  not  determined  syntactically; 
inference  variables  are  used  instead.  The  a  substitution  is  constructed  together  with  <b/  and  can  be  viewed 
as  a  renaming  between  normal  variables  and  meta-variables.  It  is  an  invertible  substitution,  as  described 
above  in  the  type  inference  section;  therefore  even  if  e  contains  inference  variables,  these  can  still  be 
uniquely  determined. 

Tactics  syntax.  Our  implementation  includes  syntactic  sugar  for  frequently-used  tactics,  in  order  to 
enable  users  to  write  concise  and  readable  proof  scripts.  Each  new  syntactic  form  expands  directly  into  a 
tactic  call,  potentially  using  the  features  described  so  far  -  implicit  arguments  through  inference  variables, 
manipulation  of  the  ambient  context  and  staging  annotations.  For  example,  we  introduce  the  following 
syntax  for  conversion,  hiding  some  implicit  arguments  and  a  static  tactic  call: 

Exact  e  EE  eqElim  {{requireEqual  @  @?  @?  @?}} 

with  the  following  type  for  eqElim: 

eqElim  :  (cf> :  ctx,  P  :@Prop,  P'  :@Prop,H  :@P,H'  :@P  =  P')  —*■  (@P') 

Intuitively,  this  syntax  is  used  at  a  place  where  a  proof  of  P'  is  required  but  we  supply  a  proof  of  the 
equivalent  proposition  P.  The  proof  of  equivalence  between  P  and  P 1  is  done  through  static  evaluation, 
calling  the  requireEqual  tactic.  Using  'f|'  for  type  synthesis  and  {1  for  type  analysis  we  get  that  the  combined 
effect  of  syntactic  elaboration  and  type  inference  is: 

b  e  (@P') 
b  Exact  e  {1  ( @P ) 

eqElim  @@P  @P'  e  {{requireEqual  @ @Prop @P  @P'}} 

Another  frequently-used  example  is  the  syntax  for  the  cut  principle  -  for  proving  a  proposition  P  and 
introducing  a  name  H  for  the  proof  to  be  used  as  a  hypothesis  in  the  rest  of  the  proof  script.  This  is 
especially  useful  for  forward-style  proofs. 


Cut  H  :  P  by  e  in  e’ 

(cut  :  {cf> :  ctx,  P ' :  @Prop,  P  :  @Prop,pf1  :  @P,  pf2  '■  iyH  :  P  in  @P'))  — *■  ( @P ')  ) 

@  @?  @?  @P  e  (vH  :P  me') 

An  example  of  a  full  proof  script  for  a  property  of  addition  that  uses  this  style  of  tactic  syntactic  sugar 
follows: 
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let  plus  _x_Sy  :  (@Vx,y  :  Nat.x  +  (succ  y)  =  succ  (x  +  yj)  = 

Intro  x  in  Intro y  in 
Instantiate 

(Natlnduction  for  z.z  +  (succ  y)  =  succ(z  +  y) 
base  case  by  Auto 
inductive  case  by  Auto) 
with  @x 

The  tactic  syntax  we  support  is  mostly  meant  as  a  proof-of-concept.  It  demonstrates  the  fact  that  proof 
scripts  resembling  the  ones  used  in  traditional  proof  assistants  are  possible  with  our  approach,  simply  by 
providing  specific  syntax  that  combines  the  main  features  we  already  support.  We  believe  that  this  kind 
of  syntax  does  not  have  to  be  built  into  the  language  itself,  but  can  be  provided  automatically  based  on 
the  available  type  information.  For  example,  it  can  be  determined  which  arguments  to  a  function  need 
to  be  concrete  and  which  can  be  left  unspecified  as  inference  variables,  as  evidenced  by  existing  implicit 
argument  mechanisms  (e.g.  in  Coq  [Barras  et  ah,  2012]).  Also,  obligations  to  be  proved  statically,  such  as 
P  =  P'  above,  can  be  also  handled,  by  registering  a  default  prover  for  propositions  of  a  specific  form  with 
the  type  inferencing  mechanism.  In  this  way,  syntax  for  tactics  defined  by  the  user  would  not  need  to  be 
explicitly  added  to  the  parser.  We  leave  the  details  as  future  work. 

Meta-generation  of  rewriters.  When  defining  inductive  types  such  as  Nat  and  List  as  shown  in  Sub¬ 
section  8.2.2,  we  get  a  number  of  axioms  like  elimNatZero  that  define  the  computational  behavior  of  the 
associated  elimination  principles.  The  fact  that  we  do  not  have  any  built-in  conversion  rule  means  that 
these  axioms  are  not  taken  into  account  automatically  when  deciding  term  equality.  Following  the  ap¬ 
proach  of  Section  7.2,  we  need  to  define  functions  that  rewrite  terms  based  on  these  axioms.  The  situation 
is  similar  when  proving  theorems  involving  equality  like: 

Vx.x  +  0  =  x 

which  is  the  example  that  prompted  us  to  develop  plusRewriterl  in  the  same  section.  Writing  such  rewrit¬ 
ers  is  tedious  and  soon  becomes  a  hindrance:  every  inductive  definition  and  many  equality  theorems 
require  a  specialized  rewriter.  Still  the  rewriters  follow  a  simple  template:  they  perform  a  number  of 
nested  pattern  matches  and  recursive  calls  to  determine  whether  the  left-hand  side  of  the  equality  matches 
the  scrutinee  and  then  rewrite  to  the  right-hand  side  term  if  it  does. 

In  order  to  simplify  this  process,  we  take  advantage  of  the  common  template  of  rewriters  and  provide  a 
syntactic  construct  that  generates  rewriters  at  the  meta-level.  This  construct  is  implemented  as  an  OCaml 
function  that  yields  a  VeriML  term  when  given  a  theorem  that  proves  an  equality.  That  is,  we  add  a 
construct  Gen  Rewriter  c  which  is  given  a  proof  c  of  type  V  •  •  •  ,lhs  =  rhs  and  generates  a  VeriML  term  that 
corresponds  to  the  rewriter  a  user  would  normally  write  by  hand.  The  rewriter  has  similar  structure  as 
described  earlier.  When  programming  the  rewriter  generator  itself,  we  use  the  normal  OCaml  type  system 
to  construct  an  appropriate  VeriML  term.  This  term  is  then  returned  as  the  expansion  of  GenRewriter  c 
and  checked  using  the  VeriML  type  system.  Thus  the  rewriter  generator  does  not  need  to  be  trusted. 

8.3.2  Translation  to  OCaml 

Our  implementation  evaluates  VeriML  programs  by  translating  them  into  OCaml  programs  which  are 
then  run  using  the  standard  OCaml  tools.  Intuitively,  the  translation  can  be  understood  as  translat¬ 
ing  dependently-typed  VeriML  expressions  into  their  simply-typed  ML  counterparts.  We  follow  this 
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Description 


VeriML  AST 


OCaml  AST 


Dependent  functions  over  contextual  terms 

type  ( X  :  [$]  t)—*  r 

introduction  XX : 

elimination  e([$]t) 

Dependent  functions  over  contexts 

type  (<f>  :  [<f>]  ctx )  — *■  r 

introduction  \(f> :  [$]  ctx.e 

elimination  e([$]$/) 

Dependent  tuples  over  contextual  terms 
type  ( X  :  [$]  t)  X  r 

introduction  (  [$]  G  e  )(Jf:[$](')xr 

elimination  let  (X,  x  )  =  e  in  e' 


Logic. term  ->  [tJ 
fun  X  :  Logic. term  =>  [ej 

[eJ  M 

Logic. ctx  ->  [r] 
fun  X  :  Logic. ctx  =>  [ej 

M  p'] 

Logic. term  *  [tJ 

(  M,  [el  ) 

let  (  X,  x  )  =  [el  in  [e'J 


Type  constructors  over  contextual  terms 

kind  UV  :K.k  [&]] 

introduction  XX  :T.r  [r! 

elimination 


Table  8.2:  Translation  of  dHOL-related  VeriML  constructs  to  simply-typed  OCaml  constructs 

approach  in  order  to  achieve  efficient  execution  of  VeriML  programs  without  the  significant  development 
cost  of  creating  an  optimizing  compiler  for  a  new  language.  We  make  use  of  the  recently-developed  Just- 
In-Time-based  interpreter  for  OCaml  [Meurer,  2010]  which  is  suitable  for  the  interactive  workflow  of  a 
proof  assistant,  as  well  as  of  the  high-quality  OCaml  compiler  for  frequently-used  support  code  and  tac¬ 
tics.  The  availability  of  these  tools  render  the  language  a  good  choice  for  the  described  approach  to  VeriML 
evaluation.  We  have  also  developed  a  complete  VeriML  interpreter  that  does  not  make  use  of  translation 
to  OCaml.  Its  implementation  follows  standard  practice  corresponding  directly  to  the  VeriML  semantics 
we  have  given  already.  Nevertheless,  it  has  been  largely  obsoleted  in  favor  of  OCaml-based  translation 
because  of  efficiency  issues:  typechecking  and  running  the  full  code  of  our  examples  presented  in  the  next 
chapter  takes  about  6  minutes  with  the  interpreter-based  evaluation,  whereas  it  takes  only  15  seconds  in 
OCaml-based  translation  coupled  with  OCamlJIT,  when  using  a  2.67  GHz  Intel  i7-620  CPU. 

The  main  translation  function  accepts  a  VeriML  computational  language  AST  and  emits  an  OCaml 
AST.  The  VeriML  AST  is  assumed  to  be  well-typed;  the  translation  itself  needs  some  type  information 
for  specific  constructs  and  it  can  therefore  be  understood  as  a  type-directed  translation.  We  make  use  of 
the  Camlp4  library  of  OCaml  that  provides  quotation  syntax  for  OCaml  ASTs. 

The  ML  core  of  VeriML  presented  in  Figure  6.1  is  translated  directly  into  the  corresponding  OCaml 
forms.  The  zHOL-related  constructs  of  Figure  6.2  are  translated  into  their  simply-typed  OCaml  counter¬ 
parts,  making  use  of  our  existing  zHOL  implementation  in  OCaml  -  the  same  one  used  by  the  VeriML 
type  checker.  For  example,  VeriML  dependent  functions  over  contextual  terms  are  translated  into  normal 
OCaml  functions  over  the  Logic.term  datatype  -  the  type  of  zHOL  terms  as  encoded  in  OCaml.  The 
fact  that  simply-typed  versions  of  the  constructs  are  used  is  not  an  issue  as  the  type  checker  of  VeriML  has 
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already  been  run  at  this  point,  providing  the  associated  benefits  discussed  in  previous  chapters.  We  give  a 
sketch  of  the  translated  forms  of  most  dHOL-related  constructs  in  Table  8.2.  Note  that  type-level  func¬ 
tions  over  extension  terms  are  simply  erased,  as  they  are  used  purely  for  VeriML  type  checking  purposes 
and  do  not  affect  the  semantics  of  VeriML  expressions. 

Let  us  now  present  some  important  points  of  this  translation.  First,  the  context  part  of  contextual 
terms  is  dropped  -  we  translate  a  contextual  term  [<£]  t  as  the  OCaml  AST  [[tj .  For  example,  the  term 

[x  :  Nat ]  Vy  :  Nat,  x>  0  — >  x  +y  >  y 

or,  in  concrete  syntax: 

[Nat]  U(Nat).U(gt  vQ  zero).gt  {plus  v0  bx)  b1 

is  translated  as: 

LPi (LConst ("Nat") , 

LPi (LApp(LApp(LConst ("gt") ,  LFVar(O)),  LConst ("zero") ) , 

LApp (LApp (LConst ("gt") , 

(LApp(LApp (LConst ("plus") ,  LFVar(O),  LBVar(l)))), 

LBVar (1) ) ) ) ) 

The  reason  why  the  context  part  is  dropped  is  that  it  is  not  required  during  evaluation;  it  is  only  relevant 
during  VeriML  type  checking.  This  is  evident  in  our  formal  model  from  the  fact  that  the  dHOL-related 
operations  used  in  the  VeriML  operational  semantics  -  substitution  and  pattern  matching  -  do  not  actually 
depend  on  the  context  part,  as  is  clear  from  the  practical  version  of  pattern  matching  using  annotated 
terms  in  Section  5.1. 

Also,  extension  variables  X  and  &  as  used  in  the  dependently-typed  constructs  are  translated  into 
normal  OCaml  variables.  This  reflects  the  fact  that  the  operational  semantics  of  VeriML  are  defined  only 
on  closed  VeriML  expressions  where  the  extension  variables  context  T  is  empty;  therefore  extension 
variables  do  not  need  a  concrete  runtime  representation.  By  representing  extension  variables  as  OCaml 
variables,  we  get  extension  substitution  for  free,  through  OCaml-level  substitution.  This  is  evidenced 
in  the  following  correspondence  between  the  VeriML  semantics  of  function  application  and  the  OCaml 
semantics  of  the  translated  expression: 

(dX  :  [$]  t'.e)  ([$]  t)  -*VeriML  e  •  ([$]  t/X) 

(fun  X  :  Logic. term  =>  e)  t — >oCaml  e[t/x] 

Uses  of  extension  variables  inside  logical  terms  are  translated  as  function  calls.  As  mentioned  in  Sec¬ 
tion  4.1,  the  usage  form  of  meta-variables  X /cr  is  understood  as  a  way  to  describe  a  deferred  substitution 
a ,  which  gets  applied  to  the  term  t  as  soon  as  X  is  instantiated  with  the  contextual  term  [$]  t .  This  is  cap¬ 
tured  in  our  implementation  by  representing X / a  as  a  function  call  subst_f  ree_list  X  a,  where  the 
free  variables  of  the  term  X  (again,  an  OCaml-level  variable)  are  substituted  for  the  terms  in  a.  Similarly, 
uses  of  parametric  contexts  <f)  stand  for  deferred  applications  of  weakening,  shifting  the  free  variables  in  a 
term  by  the  length  of  the  specified  context,  when  cf>  is  instantiated. 

Pattern  matching  over  dHOL  terms  is  translated  following  the  same  approach  into  simply-typed  pat¬ 
tern  matching  over  the  OCaml  datatypes  Logic  .term  and  Logic .  ctx  that  encode  dHOL  logical  terms 
and  contexts  respectively.  Patterns  Tp  as  used  in  the  VeriML  construct  become  OCaml  patterns  over 
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those  data  types;  unification  variables  from  become  OCaml  pattern  variables.  In  this  way  we  reuse 
pattern  matching  optimizations  implemented  in  OCaml.  The  main  challenge  of  this  translation  is  main¬ 
taining  the  correspondence  with  the  pattern  matching  rules  described  in  Section  5.1.  Most  rules  directly 
correspond  to  a  constructor  pattern  for  dHOL  terms  -  for  example,  the  rule  for  sorts:  we  can  simply 
match  a  term  like  LSort(LSet)  against  a  pattern  like  LSort(s),  where  s  is  a  pattern  variable.  Other 
rules  require  a  combination  of  a  constructor  pattern  and  of  guard  conditions,  such  as  the  rule  for  appli¬ 
cation:  matching  the  term  LApp(tl,t,s,t2)  corresponding  to  the  term  (tx:  t  :  s )  t2  against  a  pattern 
LApp  (tl,,t’,s,,t2’)  requires  checking  that  s  =  s  ’ .  Similarly,  the  exact  pattern  X  /  a  where  X  is  not 
a  unification  metavariable,  used  matching  a  term  t  against  an  already-instantiated  metavariable,  requires 
checking  that  X  =  t,  implemented  as  a  guard  condition  lterm_equal  t  t  ’ .  Last,  some  rules  such  as 
function  formation  need  to  apply  freshening  after  matching. 

Though  we  reuse  the  dHOL  implementation  in  order  to  translate  the  related  parts  of  VeriML  ex¬ 
pressions,  this  is  not  a  hard  requirement.  We  can  replace  the  OCaml  representation  of  dHOL  terms  - 
for  example,  we  can  translate  them  into  terms  of  the  HOL-Light  system,  which  is  also  implemented  in 
OCaml  and  uses  a  similar  logic.  Translating  a  VeriML  tactic  would  thus  result  in  an  HOL-Light  tactic.  In 
this  way,  the  VeriML  implementation  could  be  seen  as  a  richly-typed  domain-specific  language  for  writing 
HOL-Light  tactics. 

8.3.3  Staging 

Supporting  the  staging  construct  of  VeriML  introduced  in  Section  6.3  under  the  interpreter-based  evalua¬ 
tion  model  is  straightforward:  prior  to  interpreting  an  expression  e,  we  call  the  interpreter  for  the  staged 
expressions  es  it  encloses;  the  interpreter  yields  values  for  them  vs  (if  evaluation  terminates  successfully); 
the  staged  expressions  are  replaced  with  the  resulting  values  vs  yielding  the  residual  expression. 

When  evaluating  VeriML  terms  through  translation  to  OCaml,  this  is  not  as  straightforward.  The 
translation  yields  an  OCaml  AST  -  a  value  of  a  specific  datatype  encoding  OCaml  expressions.  We  need 
to  turn  the  AST  into  executable  code  and  evaluate  it;  the  result  value  is  then  reified  back  into  an  OCaml 
AST,  yielding  the  translation  of  the  staged  expression.  This  description  essentially  corresponds  to  staging 
for  OCaml.  The  VeriML  translator  could  thus  be  viewed  as  a  stage-1  OCaml  function,  which  evaluates 
stage-2  expressions  (the  translations  of  staged  VeriML  expressions)  and  yields  stage-3  executable  code  (the 
translation  of  the  resulting  residual  expressions). 

Still,  staging  is  not  part  of  Standard  ML  and  most  ML  dialects  do  not  support  it;  the  OCaml  lan¬ 
guage  that  we  use  does  not  support  it  by  default.  Various  extensions  of  the  language  such  as  MetaOCaml 
[Calcagno  et  ah,  2003]  and  BER  MetaOCaml  have  been  designed  precisely  for  this  purpose  but  do  not 
support  other  features  of  the  language  which  we  rely  on,  such  as  support  for  Camlp4.  We  address  this 
issue  by  evaluating  OCaml  ASTs  directly  through  the  use  of  the  OCaml  toplevel  library,  which  can  be 
viewed  as  a  library  that  provides  access  to  the  OCaml  interpreter.  The  OCaml  AST  is  passed  directly 
to  the  OCaml  interpreter;  it  yields  an  OCaml  value  which  is  reified  back  into  an  OCaml  AST.  Reifi¬ 
cation  requires  being  able  to  look  into  the  structure  of  the  resulting  value  and  is  thus  only  possible  for 
specific  datatypes,  such  as  dHOL  tuples,  integers  and  strings;  we  disallow  using  the  staging  construct  for 
expressions  of  other  types  that  cannot  be  reified,  such  as  functions  and  mutable  references. 

There  are  thus  two  distinct  interpreters  involved  in  the  evaluation  of  a  VeriML  program:  one  is  the 
interpreter  used  during  translation  from  VeriML  to  OCaml,  whose  purpose  is  to  execute  staged  VeriML 
expressions;  another  is  the  interpreter  (or  compiler)  used  after  the  translation  is  complete,  in  order  to 
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evaluate  the  result  of  the  translation  -  the  translation  of  the  residual  VeriML  program.  An  interpreter 
has  to  be  used  for  the  first  stage,  a  consequence  of  how  we  are  side-stepping  the  lack  of  staging  support 
in  OCaml.  Still,  we  can  make  sure  that  the  interpretation  overhead  is  minimized  by  using  the  OCamlJIT 
interpreter,  and  also  by  making  sure  that  the  interpreter  is  mostly  used  to  make  calls  to  already-compiled 
code.  We  achieve  this  by  splitting  our  code  into  separate  files  and  using  separate  compilation. 

From  the  two  interpreters  involved  in  evaluation,  the  first  one  corresponds  to  the  static  evaluation 
semantics  — y;  the  second  to  dynamic  evaluation  — ►,  as  described  in  Section  6.3.  The  two  interpreters 
do  not  share  any  state  between  them,  contrary  to  the  semantics  that  we  have  given.  We  partially  address 
the  issues  arising  from  this  by  repeating  top-level  definitions  in  both  interpreters,  so  that  an  equivalent 
state  is  established;  we  assume  that  staged  VeriML  expressions  do  not  alter  the  state  in  a  way  that  alters 
the  evaluation  of  dynamic  expressions. 

8.3.4  Proof  erasure 

In  order  to  be  able  to  control  whether  an  expression  is  evaluated  under  proof-erasure  semantics  or  not, 
we  make  normal  semantics  the  default  evaluation  strategy  and  include  a  special  construct  denoted  as 
{e}t rusted,  to  cvak|atc  the  expression  e  under  proof-erasure.  We  implement  the  proof-erasure  semantics  as 
presented  in  Section  6.4,  as  erasure  proof  objects  and  evaluation  under  the  normal  semantics.  We  change 
the  translation  of  /HOL  terms  to  be  a  type-directed  translation.  When  a  term  sorted  under  Prop  is  found, 
that  is,  a  term  corresponding  to  a  proof  object,  its  translation  into  an  OCaml  AST  is  simply  the  translation 
of  the  admit  constant.  More  precisely,  the  translation  is  a  conditional  expression  branching  on  whether 
we  are  working  under  proof  erasure  or  not:  in  the  former  case  the  translation  is  the  trivial  admit  constant 
and  in  the  latter  it  is  the  full  translation  of  the  proof  object.  The  exact  mode  we  are  under  is  controlled 
through  a  run-time  mutable  reference,  which  is  what  the  {e}truste^  construct  modifies.  In  this  way,  all 
enclosed  proof  objects  in  e  are  directly  erased. 

8.3.5  VeriML  as  a  toplevel  and  VeriML  as  a  translator 

We  include  two  binaries  for  VeriML:  a  VeriML  toplevel  and  a  VeriML  translator.  The  former  gives  an 
interactive  read-eval-print-loop  (REPL)  environment  as  offerred  by  most  functional  languages.  It  works 
by  integrating  the  VeriML -to-OCaml  translator  with  the  OCaml  interpreter  and  is  suitable  for  experi¬ 
mentation  with  the  language  or  as  a  development  aid.  The  latter  is  used  to  simply  record  the  OCaml 
code  yielded  by  the  VeriML-to-OCaml  translation.  When  combined  with  the  OCaml  compiler,  it  can  be 
viewed  as  a  compiler  for  VeriML  programs. 

The  VeriML  toplevel  is  also  suitable  for  use  as  a  proof  assistant.  When  defining  a  new  VeriML  ex¬ 
pression  -  be  it  a  tactic,  a  proof  script  or  another  kind  of  computational  expression  -  the  VeriML  type 
checker  informs  us  of  any  type  errors.  By  leaving  certain  parts  of  such  expressions  undetermined,  such 
as  a  part  of  a  proof  script  that  we  have  not  completed  yet,  we  can  use  the  type  information  returned  by 
the  type  checker  in  order  to  proceed.  Furthermore,  we  are  also  informed  if  a  statically-evaluated  proof 
expression  fails.  We  have  created  a  wrapper  for  the  toplevel  for  the  popular  Proof  General  frontend  to 
proof  assistants  [Aspinall,  2000],  which  simplifies  significantly  this  style  of  dialog-based  development. 
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Chapter  9 

Examples  and  Evaluation 


We  will  now  present  a  number  of  examples  that  we  have  implemented  in  VeriML.  We  will  follow  the  ideas 
from  Chapter  7  in  building  a  conversion  rule  that  supports  /^-equivalence,  congruence  closure  and  arith¬ 
metic  simplifications  in  successive  layers.  Such  extensions  to  the  conversion  rule  have  required  significant 
engineering  effort  in  the  past  [e.g.  Strub,  2010];  their  implementation  in  current  proof  assistants  makes 
use  of  techniques  such  as  proof  by  reflection  and  translation  validation  [Barras  et  ah,  2012],  The  VeriML 
design  allows  us  to  express  them  in  a  natural  style.  We  will  also  present  a  first-order  automated  theorem 
prover  which  will  be  used  to  simplify  some  of  the  proofs  involved.  We  will  use  syntax  that  is  close  to  the 
actual  syntax  used  by  our  prototype  implementation,  with  slight  changes  for  presentation  purposes. 

9.1  Basic  support  code 

The  basic  VeriML  library  includes  definitions  of  Standard  ML  datatypes,  such  as  bool,  option  and  list, 
along  with  auxiliary  functions  over  these.  For  example,  the  type  of  lists  and  the  associated  map  and  fold 
functions  are  defined  in  Code  Listing  9.1,  as  well  as  the  option  type  with  associated  functions  and  syntax. 

We  also  define  a  number  of  simple  proof-producing  functions  to  lift  dFlOL  proof  object  constructors 
to  the  computational  level.  We  provide  tactic  syntactic  sugar  for  them,  as  described  in  Chapter  8.  For 
example,  the  function  eqElim  in  Code  Listing  9.2  lifts  the  EqElim  typing  rule  (in  Figure  3.10)  from  the 
level  of  dHOL  proof  objects  to  the  level  of  VeriML  proof  expressions  of  type  hoi  ( [F]  P) . 

The  code  uses  concrete  syntax  that  we  have  not  discussed  so  far.  We  remind  the  reader  that  VeriML 
proof  expressions  are  expressions  of  the  type  ([F]  P)  =  (G  :  [F]  P )  X  unit  where  P  is  a  proposition;  that  is, 
dependent  tuples  where  the  first  argument  is  a  proof  object  upon  successful  evaluation  and  the  second  is 
the  unit.  We  write  this  type  as  hoi  ( [F]  P)  in  the  concrete  syntax.  Also,  we  use  @  to  refer  to  the  ambient 
context,  denoted  as  @  in  the  previous  chapter.  Following  the  same  notation  we  write  contextual  terms 
[F]  t  where  F  is  exactly  the  ambient  context  as  @t.  In  this  notation,  @  binds  as  far  to  the  left  as  possible, 
capturing  all  the  following  logical  terms  until  another  computational  term  is  encountered. 

The  code  of  the  function  itself  is  straightforward:  it  opens  up  the  dependent  tuples,  making  the  meta¬ 
variables  HI  and  H2  hold  the  proof  objects  contained  therein;  using  these  it  creates  a  new  proof  object, 
which  it  wraps  inside  a  dependent  tuple.  We  introduce  the  following  syntactic  sugar  for  this  tactic,  in 
order  to  omit  all  arguments  but  the  proof  expressions: 

"Exact  el  by  e2"  ::=  eqElim  0  0?  0?  el  e2 
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1  type  list  =  fun  a  :  *  =>-  rec  t  :  ★  =>  Unit  +  a  *  t  ; ; 

2  let  nil  =  fun  a  =>-  fold(  ini  (unit),  list  a  )  ;; 

3  let  cons  =  fun  a  hd  tl  =>  fold(  inr(  (hd,  tl)  ))  ;; 

4 

5  letrec  listmap  =  fun  a  :  ★  =>•  fun  b  :  *  =>-  fun  f  :  a  — *  b  =>-  fun  1  :  list  a  =>- 

6  match  unfold  1  with 

7  ini  u  i— ►  nil 

8  I  inr  (hd,  tl)  >— *■  cons  _  (f  hd)  (listmap  f  tl)  ;  ; 

9 

10  letrec  listfold  =  fun  (a  b  :  -*•)  (f  :  b  — *■  a  — *  b)  start  =>  fun  1  :  list  a  => 

11  match  unfold  1  with 

12  ini  u  i— ►  start 

13  I  inr  (hd,  tl)  >— >  f  (listfold  f  start  tl)  hd  ;  ; 

14 

15  type  option  =  fun  a  :  *  =>-  a  +  Unit  ; ; 

16  let  optionalt  =  fun  a  :  *■  =>-  fun  tl  :  option  a  =>-  fun  t2  :  unit  — ►  option  a  =>- 

17  match  tl  with 

is  ini  s  =>  s 

19  I  inr  u  =>  t2  ()  ;  ; 

20  "el  | |  e2"  :=  optionalt  _  el  (fun  u  =>  e2)  ;; 

21 

22  let  optionforce  =  fun  a  :  *  =>-  fun  t  :  option  a  => 

23  optionalt  _  t  (fun  u  =>  error) ;  ; 

24 

25  let  optionret  =  fun  a  :  *  =>-  fun  t  :  a  =>  inl(  t  ); 

26  let  optionbind  =  fun  a  b  :  *  =>-  fun  t  :  option  a  =>  fun  f  :  a  — *  option  b  =>- 

27  match  t  with 

28  ini  s  >— *■  f  s 

29  I  inr  u  i— ►  inr  ()  ;  ; 

30  "do  xl  <—  el;  xn  <-  en;  return  e"  :  = 

31  optionbind  el  (fun  xl  => 

32  ... 

33  optionbind  en  (fun  xn  =>- 

34  optionret  e)  ...  )  ;  ; 

Code  Listing  9.1:  Definition  of  basic  datatypes  and  associated  functions 
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1  let  eqElim  = 

2  fun  <j)  :  ctx,  PI  :  ©Prop  ,  P2  :  ©Prop  , 

3  pfl  :  hoi (@P1)  ,  pf 2  :  hol(@Pl  =  P2)  =>- 

4  let  <  HI  >  =  pfl  in 

5  let  <  H2  >  =  pf2  in 

e  <  ©conv  HI  H2  >  :  hol(@P2)  ;; 

7 

s  let  intro  =  fun  cf)  :  ctx,  T  :  ©Type,  P  :  [©,  x  :  T]  .Prop  , 

9  pf  :  hol([@,  x  :  T] .P)  => 

10  let  <  [  ©,  x  :  T  ]  .pf 

u  <  ©fun  x  :  T  =>•  pf  > 

12  "Intro  x  :  T  in  e"  :  :=  intro  ©  @T  (v  x  :  T  in  @?)  (v  x  :  T  in  e) 

13  "Intro  x  in  e"  :  :=  intro  ©  @?  (v  x  :  ?  in  @?)  (v  x  :  ?  in  e) 

14 

is  let  assume  =  fun  (f>  :  ctx,  P  :  ©Prop,  P’  :  [  ©,  x  :  P  ]  .Prop  , 

16  pf  :  hol([  ©,  x  :  P]  .P>)  =>- 

17  let  <  [@,  x  :  P  ]  .pf 

is  <  ©fun  x  :  P  =>•  pf  > 

19  "Assume  H  :  P  in  e"  : :=  assume  ©  @?  (v  H  :  P  in  @?)  (v  H  :  P  in  e) 

20  "Assume  H  in  e"  : :=  assume  ©  @?  (v  H  :  ?  in  @?)  (v  H  :  ?  in  e) 

21 

22  let  cutpf  =  fun  <j)  :  ctx,  P  :  ©Prop,  P’  :  ©Prop  , 

23  pfl  :  hoi (  [©  ,  H  :  P ’ ]  . P  )  ,  pf2  :  hol(  @P>  )  =>- 

24  let  <  [©  ,  H  :  P’J.pfl  >  =  pfl  in 

25  let  <  pf2  >  =  pf2  in 

26  <  ©pfl/[id_<^,  pf 2  ]  >  :  hol(  ©P  )  ;; 

27  "Cut  H  :  P’  by  el  in  e2"  : :=  cut  ©  ©?  ©P’  (v  H  :  P’  in  e2)  el 

28  "Cut  H  by  el  in  e2"  :  :=  cut  ©  ©?  ©?  (v  H  :  ?  in  e2)  el 

Code  Listing  9.2:  Examples  of  proof  object  constructors  lifted  into  VeriML  tactics 


>  =  pf  in 

:  hoi (@P1  ->  P2)  ;  ; 


>  =  pf  in 
:  hoi (@Vx . P)  ;; 
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In  the  rest  we  will  often  omit  definitions  of  such  syntactic  shorthands;  we  will  note  implicit  arguments 
with  brackets  instead.  It  is  understood  that  these  are  then  instantiated  implicitly.  We  give  more  examples 
of  such  proof  constructor  lifting  functions  along  with  their  syntactic  sugar  in  Code  Listing  9.2.  In  all 
functions  note  that  when  we  open  up  dependent  tuples,  we  annotate  metavariables  with  their  context 
unless  it  is  the  ambient  context. 

A  proof  expression  of  the  VP,  Q  :  Prop.P  =  Q  — *  (P  — »  Q)  theorem  of  higher-order  logic  is  given  as 
follows: 

Theorem  propeq_impl  :  VP,Q  :  Prop.P  =  Q  — *■  (P  — »■  Q)  :  = 

Intro  P  :  Prop  in  Intro  Q  :  Prop  in 

Assume  HI  :  P  =  Q  in 

Assume  H2  :  P  in 

Exact  <  H2  >  by  <  HI  >  ; ; 


9.2  Extensible  rewriters 

In  Section  7.1,  we  mentioned  that  we  have  implemented  some  infrastructure  for  a  user-extensible  defi¬ 
nitional  equality  checker.  We  develop  this  infrastructure  before  implementing  any  non-trivial  notion  of 
definitional  equality  such  as  /3-equality,  as  it  will  allow  us  to  simplify  such  implementations.  The  code  is 
based  around  rewriters  and  equality  checkers:  rewriters  perform  one  step  of  a  relation  such  as  t  — >R  t' , 
simplifying  t  into  the  form  t';  equality  checkers  decide  whether  two  terms  are  equal.  A  rewriter  can  be 
turned  into  an  equality  checker  through  a  function  similar  to  def Equal  as  seen  before,  which  essentially 
computes  the  symmetric,  transitive,  reflexive  and  compatible  closure  =R  of  — >R.  This  assumes  that  — >R 
is  confluent,  something  that  we  do  not  enforce. 


Rewriters.  The  type  of  rewriters  is  defined  as: 

type  rewriter_t  =  (  {</>  :  ctx}  ,  {T  :  ©Type},  e  :  @T  )  — » 
(  e>  :  @T  )  X  hol(  @e  =  e’  )  ; ; 


Some  rewriting  relations  might  proceed  by  structural  recursion.  For  example,  rewriting  to  weak  head- 
normal  form  with  respect  to  /3-reduction  is  defined  as  follows: 

t  t'  — > q  t"\t' /x\  when  t  — *  n  Xx.t" 

Furthermore,  we  build  rewriters  by  composing  many  rewriters  together: 


U---U 


It  makes  sense  to  use  — >R  for  the  recursive  calls  used  by  any  one  of  the  — >R  rewriters.  In  that  way, 
progress  made  by  one  rewriter  will  trigger  further  progress  in  another.  Consider  the  following  example 
which  makes  use  of  an  alternate  definition  of  addition: 


( elimNat  Xy.y  ( Xp.Xr.Xy.succ  (r  y))  0)  5 

Though  the  above  rule  for  /3-reduction  does  not  apply,  a  different  rewriter  — can  reduce  the  function 
term  to  Xy.y.  Then  the  /3-reduction  rule  can  make  progress. 

In  order  to  support  this,  we  write  each  — >R  rewriter  in  open  recursion  style,  expecting  the  current 
‘full’  — >R  rewriter  as  an  argument.  We  call  each  — >R .  rewriter  as  a  rewriter  module.  Their  type  is: 
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i  let  build  rewriter 
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fun  rewriters_list  :  list  rewriter_module_t  => 
letrec  rewriter  :  rewriter_t  = 
fun  {< j)  T}  e  => 

(let  test_progress  = 

fun  res  :  <  e;  :  @T  >  hol(  @e  =  e;  )  => 
let  <  e}  >  =  res  in 
holmatch  @e*  as  x  return  bool  with 
@e  ►  false 
I  @e5  •— i >•  true 
in 

let  idelem  =  <  @e  ,  @refl  e  >  in 
let  f irst_successful  = 
listfold 

(fun  res  currewritemodule  => 

(if  test_progress  res  then 
res 
else 

currewritemodule  rewriter  @e)) 

idelem 

rewrit ers_list 
in 

if  test_progress  f irst_successful  then 

let  <  e*  ,  pfe*  >  =  f irst_successful  in 
let  <  e,;  ,  pfe,;  >  =  rewriter  @eJ  in 
<  @e,;  ,  @trans  pfe’  pfe55  > 
else 

f irst_successful) 
in 

rewriter  ; ; 


Code  Listing  9.3:  Building  a  rewriter  from  a  list  of  rewriter  modules 
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1  let  global_rewriter_modules  =  ref  nil  :  ref  (list  rewriter_module_t)  ; ; 

2  let  def ault_rewriter  =  fun  { <f>  T}  e  => 

3  build_rewriter  ! global_rewriter_modules  @e  ;; 

4 

5  let  global_rewriter_add  =  fun  r  => 

6  global_rewriter_modules  :=  listsnoc  ! global_rewriter_modules  r  ;; 

7  let  global_rewriter_add_many  =  fun  r  =>- 

8  global_rewriter_modules  :=  listappend  !global_rewriter_modules  r  ;; 

9  let  global_rewriter_add_top  =  fun  r  => 

10  global_rewriter_modules  :=  cons  r  ! global_rewriter_modules  ;; 

11  let  global_rewriter_remove_top  =  fun  u  => 

12  match  ! global_rewriter_modules  with 

13  nil  i— ►  unit 

14  I  cons(hd,tl)  >— *■  global_rewriter_modules  :=  tl  ;; 

15  "Temporary  Rewriter  el  in  e2"  : := 

16  global_rewriter_add_top  el  ; 

17  let  res  =  e2  in 

is  global_rewriter_remove_top  () ;  res 


Code  Listing  9.4:  Global  registering  of  rewriter  modules 

type  rewriter_module_t  = 
rewriter_t  — * 

(  {<f>  :  ctx}  ,  {T  :  ©Type},  e  :  @T  )  — >■ 

(  e'  :  @T  )  X  hol(  @e  =  e’  )  ;; 

The  relationship  between  full  rewriters  and  rewriter  modules  corresponds  to  the  relationship  between  the 
functions  rewriteBetaNat  and  rewriteBetaNatStep  presented  in  Section  7.1.  That  is,  rewriter  modules  are 
expected  to  perform  a  single  rewriting  step,  whereas  full  rewriters  are  expected  to  proceed  until  a  normal 
form  is  reached. 

We  build  a  full  rewriter  from  a  list  of  rewriter  modules  through  the  code  presented  in  Code  Listing  9.3. 
Intuitively,  the  full  rewriter  — >R  tries  to  make  progress  towards  a  normal  form  by  trying  each  rewriter 
module  successively.  The  next  step  is  given  by  the  first  rewriter  module  which  does  make  progress,  yield¬ 
ing  a  term  t'  which  is  not  syntactically  identical  to  the  original  term  L .  The  process  continues  until  no 
further  progress  can  be  made. 

We  define  a  global  mutable  list  of  rewriter  modules  and  a  default  rewriter  that  uses  build_rewriter 
to  combine  them  together,  as  shown  in  Code  Listing  9.4.  We  also  provide  some  management  functions, 
adding  rewriters  as  the  first  or  last  one  to  be  used,  as  the  order  in  which  they  are  executed  is  important: 
for  example,  normalizing  0  +  x  takes  one  step  through  a  rewriter  that  evaluates  addition  directly,  but 
multiple  steps  if  going  through  more  basic  reductions  (unfolding  of  the  definition  of  +,  multiple  /5-steps 
and  a  natural  number  elimination  step).  Also,  we  define  a  function  to  remove  the  top  element  of  the  list, 
which  is  mostly  used  in  order  to  define  temporary  rewriters  that  are  only  used  within  one  block  of  code. 

Equality  checkers.  The  type  of  equality  checkers  is  identical  to  the  type  of  def  Equal  as  presented  in 
Chapter  7: 
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1  let  equalchecker_syntactic  :  equalchecker_t  = 

2  fun  T}  el  e2  => 

3  holmatch  @e2  as  e2}  return  option(hol (@el  =  e2J))  with 

4  @el  •— ►  some  <  @refl  el  > 

5  I  @e2  *  •— ►  none  ;  ; 
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let  equalchecker_closure  = 
fun  rewriter  :  rewriter_t  => 
letrec  check_equal  =  fun  { (f>  T}  els  e2s  => 
let  <  el,  pfel  >  =  rewriter  @els  in 

let  <  e2,  pfe2  >  =  rewriter  @e2s  in 

do  <  pf  >  <— 

(holmatch  @T,  @el,  @e2  with 

I  @T,  Q(al  :  T*  — ►  T)  bl,  @(a2  :  T*  — >•  T)  b2  »— >• 
do  <  pfa  >  <—  check_equal  @al  @a2  ; 

<  pfb  >  <—  check_equal  @bl  @b2  ; 

return  G1  :  hol(  @al  bl  =  a2  b2  ) 

I  @T’  ’  — ►  T’  ,  @/lx  :  T’Cal  ,  @/lx  :  T;,.a2  ->• 
do  <  [@,  x  :  T’ ’] .pfa  >  <—  vx:T.check_equal  Sal  @a2  ; 
return  G2  :  hol(  @/lx  :  T’^.al  =  ^x  :  T,,.a2  )  ;; 

I  ...  ); 

return  G 
in 

check_equal 


:  hol(  @els  =  e2s  ) 

f  f 


Code  Listing  9.5:  Basic  equality  checkers:  syntactic  equality  and  compatible  closure 

type  equalchecker_t  =  (  {c f>  :  ctx},  {T  :  ©Type}-  ,  el  :  @T  ,  e2  :  @T  )  — »• 

option  (hol(@el  =  e2))  ;; 

We  will  not  use  the  open  recursion  style  shown  above  for  equality  checkers,  so  each  module  we  develop 
should  have  the  above  type.  The  simplest  example  is  a  checker  that  can  only  decide  syntactic  equality 
between  two  terms  as  presented  in  Code  Listing  9.5,  lines  1  through  5. 

The  next  example  we  develop  is  the  “contextual  closure”  equality  tester,  which  compares  two  terms 
structurally,  using  the  rewriter  at  each  step .  This  is  mostly  identical  to  the  checker  presented  in  Section  7.1, 
where  the  rewriteBetaNat  function  is  used  as  the  rewriter  inside  the  defEqual  equality  checking  function. 
We  thus  present  a  sketch  of  this  function  in  Code  Listing  9.5  and  refer  the  reader  to  Section  7.1  for  the 
missing  pattern  matching  cases. 

Since  no  equality-related  automation  is  built  up  at  this  point,  we  need  to  provide  explicit  detailed 
proofs  for  the  missing  proof  obligations  in  this  function.  The  fact  that  we  perform  these  proofs  at  such 
an  early  stage  in  our  development  will  allow  us  to  take  them  for  granted  in  what  follows  and  never  reason 
explicitly  about  steps  related  to  contextual  closure  again.  The  full  proof  objects  follow: 

G1  =  <  Oconv  (conv  (refl  (al  bl))  (subst  (x.al  bl  =  al  x)  pfb)) 

(subst  (x.al  bl  =  x  b2)  pfa)  > 
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1  let  equalchecker_compose_many  =  fun  equalcheckers  :  list  equalchecker_t  => 

2  fun  {cf  TJ  el  e2  => 

3  listfold  (fun  prf  checker  => 

4  prf  I  I  (do  return  checker  @el  @e2)) 

5  (equalchecker_syntactic  @el  @e2) 

6  equalcheckers  ; ; 

7 

8  let  build_equalchecker  =  fun  rewriter  equalcheckers_list  => 

9  equalchecker_closure  rewriter 

10  (equalchecker_compose_many  equalcheckers_list)  ; ; 

11 

12  let  global_equalcheckers  =  ref  nil  ; ; 

13 

14  let  def ault_isequal  = 

15  build_equalchecker  def ault_rewriter  ! global_equalcheckers  ;; 

16  let  require_isequal  = 

17  fun  {(f>  T}  e  e’  => 

is  match  def ault_isequal  @e  @e’  with 

19  some  (prf)  >— »•  prf 

20  I  none  >— *■  error  ;  ; 


Code  Listing  9.6:  Global  registration  of  equality  checkers  and  default  equality  checking 

G2  =  <  (ScongLam  (x :  T’  1  .  pfa/  [id_<^> ,  x]  )  > 

G  =  <  Oconv  (conv  pf  (subst  (x.  x  =  e2s)  (symm  pfel))) 

(subst  (y.  el  =  y)  (symm  pfe2))  > 

Just  as  in  the  case  of  rewriters,  we  create  a  default  equality  checker  which  combines  a  list  of  others.  We 
register  available  equality  checkers  in  a  global  mutable  list.  We  expect  each  checker  in  the  list  to  be  a 
‘local’  checker  -  that  is,  it  does  not  form  the  compatible  closure  seen  above  on  its  own.  Instead,  we  take 
the  compatible  closure  after  all  local  checkers  are  combined  into  one  and  make  the  resulting  checker  the 
default  one.  These  are  shown  in  Code  Listing  9.6. 

We  also  define  syntactic  sugar  for  calls  to  require_isequal  where  all  arguments  are  inferred;  also  a 
form  where  the  call  happens  statically,  following  the  insights  from  Chapter  7,  and  syntax  for  other  tactics 
that  require  equality  proofs.  In  this  way,  require_equal  becomes  similar  to  the  conversion  rule  yet  can 
be  extended  using  more  rewriters  and  checkers. 

"ReqEqual"  ::=  require_isequal  0  0?  0?  0? 

"StaticEqual"  : : =  {{  require_isequal  0  0?  0?  0?  }} 

"Exact  e"  ::=  Exact  e  by  StaticEqual 

"Cut  H  :  el  =  e2  in  e3"  ::=  Cut  H  :  el  =  e2  by  StaticEqual  in  e3 


9.3  Naive  equality  rewriting 

After  having  set  up  the  infrastructure,  we  are  ready  to  develop  non-trivial  equality  checking.  Our  first 
concern  is  to  have  a  way  to  take  existing  hypotheses  into  account.  For  example,  if  we  already  know  that 
t]  =  t2,  the  two  terms  should  be  indistinguishable  for  the  rest  of  our  reasoning,  eliminating  the  need  for 
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explicit  rewriting  by  the  user.  This  sort  of  reasoning  is  ubiquitous  and  by  making  it  part  of  the  default 
equality  checking  at  an  early  point,  we  simplify  the  implementation  of  later  extensions. 

We  first  develop  a  naive  way  of  supporting  such  reasoning:  we  add  a  term  rewriter  that  substitutes 
all  occurrences  of  tx  to  t2  -  or  the  inverse  -  when  a  hypothesis  tx  =  t2  exists.  In  this  way,  terms  come 
into  a  ‘normal’  form  where  the  equality  hypotheses  have  been  taken  into  account  before  being  checked 
for  syntactic  equality.  This  strategy  has  numerous  shortcomings.  For  example,  the  presence  of  a  cycle  in 
the  equality  hypotheses  leads  to  an  infinite  loop  -  consider  the  case  where  x—y  and  y  =  x.  It  is  also  very 
inefficient  and  can  only  prove  simple  cases  of  using  the  hypotheses.  The  obvious  benefit  is  its  simplicity. 
The  code  for  this  naive  rewriter  is  presented  in  Code  Listing  9.7.  The  auxiliary  function  gather_eqhyps 
isolates  equality  hypotheses  from  the  current  context  and  records  them  into  a  list. 

In  our  actual  implementation  we  try  both  directions  for  rewriting,  as  each  direction  is  able  to  prove  a 
different  set  of  facts.  We  add  this  rewriter  to  the  default  one  through  the  global_rewriter_add  function 
seen  earlier.  We  are  then  able  to  directly  prove  simple  lemmas  such  as  the  following: 

Lemma  testl  :  Vx,y,z,f,g.x  =  y— >  g  =  f  — y  =  z  — *■  f  x  =  g  z  :  = 

Intro  x  y  z  f  g  in  Assume  HI  H2  H3  in 
ReqEqual  ; ; 

9.4  Equality  with  uninterpreted  functions 

As  mentioned  above,  the  naive  strategy  for  incorporating  hypothesis  in  equality  checking  suffers  from  a 
number  of  problems.  In  this  section  we  will  present  the  code  for  a  sophisticated  procedure  that  does  the 
same  thing  in  an  efficient  and  scalable  way.  We  will  use  an  imperative  union-find  algorithm  to  construct 
equivalence  classes  for  terms  based  on  the  available  hypotheses.  It  also  takes  the  form  of  terms  into 
account,  having  special  provisions  for  function  applications:  for  example,  if  we  know  that  f  x  =  y,  then 
the  extra  knowledge  that  f  —  g  will  make  all  three  terms  f  x,y  and  g  x  part  of  the  same  equivalence  class. 
Thus  the  equality  checker  we  will  construct  is  essentially  a  decision  procedure  for  congruence  closure  or  the 
theory  of  equality  with  uninterpreted  functions,  as  this  theory  is  referred  to  in  the  SAT/SMT  literature. 
In  fact  our  implementation  is  a  direct  VeriML  adaptation  of  the  standard  textbook  algorithm  for  this 
procedure  [e.g.  Bradley  and  Manna,  2007,  Kroening  and  Strichman,  2008],  This  showcases  the  fact  that 
VeriML  allows  us  to  implement  sophisticated  decision  procedures  without  requiring  significant  changes 
to  the  underlying  algorithms  and  data  structures. 

Formally,  the  theory  of  equality  with  uninterpreted  functions  is  the  combination  of  the  following 
theorems: 

refl  :  Vx.x  =  x 

symm  :  Vx,y.x  =  y— >y  =  x 

trans  :  Vx,y,z.x  =  y— >y  =  z— >x  =  z 

congAppl  :  Vf,x,y.x  =y->fx=fy 

congApp2  :  Vf,g,x.f  =  g  — ►  f  x  =  gx 

Intuitively,  the  automation  functions  we  have  developed  already  include  explicit  proofs  involving  these 
theorems.  Ideally  we  would  thus  like  not  to  have  to  repeat  such  proofs  in  the  development  of  our  decision 
procedure.  We  will  show  that  this  is  indeed  the  case. 

The  basic  idea  of  the  algorithm  is  the  following:  every  term  t  has  a  parent  term  t'  which  it  is  equal  to. 
If  the  parent  term  t '  is  identical  to  the  term  t  itself,  then  the  term  t  is  the  representative  of  the  equivalence 
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type  eqhyps_t  =  fun  { <f>  :  ctx}  =>-  list  (  (  {T  :  @Type},  tl  :  @T,  t2  :  @T  )  X 

hoi (  @tl  =  t2  ))  ; ; 
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letrec  gather_eqhyps  : 
holmatch  cf>  with 

[  cf>0 ,  H  :  tl  =  t2  ]  !-> 
let  @  =  <f> 0  in 
let  res  =  gatherhyps  @  in 
v  H  :  tl  =  t2  in 
cons  <  @tl,  @t2,  @H  >  res 
I  [  (f> 0,  H  :  (P  :  Prop)  ]  ►  gatherhyps  [  cf> 0  ] 

I  [  (f> 0,  t  :  (T  :  Type)  ]  •— >■  gatherhyps  [  <f> 0  ] 

I  [  <f> 0,  t  :  Type]  >— »•  gatherhyps  [  cf> 0  ]  ;; 

I  []  nil 

let  rewriter_naive_eq  :  rewriter_module_t  = 
letrec  subst  : 

fun  {(fry  hyps 
let  res  = 
listfold 
(fun  cur  elm  => 

cur  I  I  (let  <  TJ  ,  tl’  ,  t2’  ,  pf  >  =  elm  in 
holcase  @T,  @t  with 

@T  ’  ,  @tl  ’  >  do  return  <  0t2)  ,  @pf  > 

I  @T  ’  ’  ,  St''  >— >  none)) 

none  eqhyps 
in 

match  res  with 

some  v  i— ►  v  |  non  •— >■  <  @t  ,  Orefl  t  > 


(  {(f>  :  ctx}  ,  hyps  :  eqhyps_t  ,  {T  :  ©Type}  )  —» 
(  t  :  @T  )  ->  (  t>  :  @T  )  X  hol(  ©t  =  t’  )  = 

m  t  => 


(  cf>  :  ctx  )  — *  eqhyps_t  =  fun  {cf}  =>• 


31  in 

32  fun  recursive  {<f>  T}  e  => 

33  let  hyplist  =  gather_eqhyps  @  in 

34  subst  hyplist  @e  ;  ; 


Code  Listing  9.7:  Naive  rewriting  for  equality  hypotheses 
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class  it  belongs  to.  Therefore  equivalence  classes  are  represented  as  a  directed  tree  of  terms  with  nodes 
pointing  towards  their  parents;  the  root  of  the  tree  is  the  representative  of  the  equivalence  class  and  has 
a  self  link.  The  find  operation  for  checking  whether  two  terms  t]  and  t2  are  equal  involves  finding  the 
representatives  tx  rcfl  and  t2  rep  for  both  by  following  parent  links  and  comparing  the  representatives.  The 
union  operation  for  incorporating  new  knowledge  about  equality  between  two  terms  t]  =  t2  consists  of 
merging  their  equivalence  classes,  making  the  representative  of  either  term  a  child  of  the  representative  of 
the  other  term. 

We  implement  the  above  description  quite  literally  in  the  union  and  find  functions  presented  in 
Code  Listing  9.10  and  Code  Listing  9.9.  The  main  departure  from  the  standard  implementation  is  that 
we  add  proofs  to  all  the  associated  data  structures.  Union  then  needs  a  proof  of  t1  =  t2  and  find  produces 
a  proof  that  the  returned  representative  trep  is  indeed  equal  to  the  original  term  t.  Another  adjustment 
we  need  to  do  is  to  represent  the  tree  as  a  hash  table  instead  of  an  array  as  done  usually;  hashing  a  term 
gives  us  an  easy  way  to  map  terms  to  hash  table  entries  (see  Code  Listing  9.8).  In  order  to  handle  function 
applications  correctly,  we  add  another  kind  of  edge  called  congruence  edge,  represented  as  sets  that  are  part 
of  every  hashtable  entry.  These  edges  associate  a  term  t  with  all  other  terms  of  the  form  t' t  or  t  t'  -  that 
is,  all  other  function  applications  which  include  t .  In  this  way,  when  we  handle  a  new  equality  hypothesis 
involving  either  t  or  t' ,  we  can  access  the  terms  where  it  appears  and  make  further  updates  to  the  equiva¬ 
lence  classes  through  the  use  of  the  theorems  congAppl  and  congApp2.  This  is  the  main  functionality  of 
merge  as  given  in  Code  Listing  9.12.  It  is  informed  of  the  congruent  terms  whose  equivalence  classes  also 
need  updating  through  the  congruent_eq  function  of  Code  Listing  9.11.  The  final  code  for  the  equality 
checking  module  that  is  then  registered  globally  is  given  in  Code  Listing  9.13. 

We  will  briefly  comment  on  some  interesting  points  of  this  code.  First,  the  hashtable  implementation 
in  Code  Listing  9.8  is  entirely  standard,  save  for  the  fact  that  keys  are  arbitrary  dHOL  terms  and  values  can 
be  dependent  on  them.  This  is  one  of  the  cases  where  we  make  use  of  the  fact  that  VeriML  allows  mixing 
logic-related  terms  and  normal  imperative  data  structures.  The  type  of  values  is  kept  parametric  for  the 
hashtable  implementation  in  order  to  allow  reuse;  more  precisely,  instead  of  being  a  simple  computational 
type  of  kind  *,  it  is  a  type  constructor  reflecting  the  dependency  on  the  keys.  In  fact,  the  type  of  keys  is 
parametric  too,  so  that  any  type  of  dHOL  domain  objects  can  become  an  entry  in  the  hashtable  -  this  is 
the  reason  for  the  implicit  T  parameter.  The  parametric  type  of  hashtables  is  then  instantiated  with  the 
concrete  value  type  constructor  euf  val  t  in  Code  Listing  9.9.  Based  on  this  definition  we  see  that  every 
term  in  the  hash  table  is  associated  with  two  mutable  fields:  one  representing  the  parent,  along  with  the 
required  proof  of  equality;  and  another  one  representing  the  set  of  terms  corresponding  to  the  congruence 
edges. 

Perhaps  the  most  surprising  fact  about  the  code  is  that  it  does  not  involve  any  manual  proof.  All  the 
points  where  a  proof  is  required  are  handled  with  StaticEqual,  which  performs  a  statically-evaluated 
call  to  the  default  equality  checking  function.  For  example,  in  Code  Listing  9.9,  line  27,  a  proof  of  f  a 
=  farep  is  discovered,  given  f  =  frep,  a  =  arep  and  frep  arep  =  farep.  This  is  where  the  code 
we  have  developed  so  far  pays  off:  all  the  functions  involved  in  our  EUF  equality  checker  are  verified, 
yet  without  any  additional  manual  proof  effort  -  save  for  setting  up  the  data  structures  in  the  right  way. 
We  have  effectively  separated  the  ‘proving’  part  of  the  decision  procedure  in  the  naive  rewriter  presented 
earlier,  from  the  ‘algorithmic’  part  of  the  decision  procedure  presented  here.  We  believe  that  further  sur¬ 
face  syntax  extensions  can  bring  the  VeriML  code  even  closer  to  the  simply  typed  version  minimizing  the 
additional  user  effort  required.  One  such  extension  would  be  to  automatically  infer  implicit  introduction 
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type  hash_t  =  fun  {cf>  :  ctx}  =>-  fun  val_t  :  ({T  :  ©Type},  key  :  @T)— => 

2  array  (option  (({T  :  ©Type},  key  :  ©T)  X  val_t  ©key)) 

3 

4  let  hashget  =  fun  {c / {val_t}  (h  :  hash_t  val_t)  {T}  key  => 

5  let  hn  =  arraylen  h  in 

6  letrec  find  =  fun  i  :  int  =>  match  h. (i)  with 

7  some  <  key’  ,  val  >  >— »•  holcase  ©key’  with 

8  ©key  >— *■  some  value 

9  I  ©key’  ’  i— ►  find  ( (i+1)  °/„hn) 

10  I  none  |->  none 

11  in 

12  find  ((hash  <  ©key  >)  '/„  hn)  ;; 

13 

14  let  hashget_f orce  =  fun  {cf>  val_tf  h  {T}-  key  =>- 

15  optionforce  (hashget  h  key)  ;  ; 

16 

17  let  hashset  =  fun  { <j>  val_t}  h  {T}  key  (val  :  val_t  ©key)  => 
is  let  hn  =  arraylen  h  in 

19  letrec  find  =  fun  i  :  int  => 

20  match  h.  (i)  with 

21  some  <  key’,  val’  >  •— ►  holcase  ©key’  with 

22  ©key  >— *■  h.  (i)  :=  some  <  Okey  ,  val  > 

23  I  @key’’  i— *■  find  ((i+l)%hn) 

24  I  none  >— *■  h.  (i)  :=  some  <  @key  ,  val  > 

25  in 

26  find  ((hash  <  ©key  >)  %  hn)  ;; 

27 

28  type  set_t  =  fun  {cf>  :  ctx}  => 

29  (hash_t  (fun  =>  Unit))  X  (list  ({T  :  ©Type}  X  hol(@T)))  ;; 

30 

31  let  setadd  =  fun  {cf>~}  ( (sethash, setlist)  as  set)  {T}-  t  =>- 

32  match  hashget  sethash  @t  with 

33  some  _  i— ►  set 

34  I  none  >— »•  hashset  sethash  @t  () ; 

35  (  sethash,  cons  <  ©t  >  setlist  )  ;  ; 

36  let  setfold  =  fun  {a  cf>~}  (f  :  (  {T}  t  )  — >  a  — *  a)  (start  :  a)  (_,  setlist)  => 

37  listfold  (fun  cur  <  t  >  =>  f  @t  cur)  start  setlist  ; ; 

38  let  setiter  =  fun  {cf>J  (f  :  (  t  )  — *  Unit)  set  => 

39  setfold  (fun  {T}  t  u  =>  f  @t)  ()  set  ;  ; 

40  let  setunion  =  fun  cf>  setl  set2=> 

41  setfold  (fun  {T}-  t  curset  =>  setadd  curset  @t)  setl  set2  ;  ; 

Code  Listing  9.8:  Implementation  of  hash  table  with  dependent  key-value  pairs  and  of  sets  of  terms  as 
pairs  of  a  hashtable  and  a  list 
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1  type  eufval_t  =  fun  {cf>  T}  key  => 

2  (ref  (  parent  :  ©T  )  X  hol(  ©key  =  parent  )  )  X 

3  (ref  set_t  )  ; ; 

4 

5  type  eufhash_t  =  fun  {cf>J  =>-  hash_t  eufval_t  ;  ; 


7  let  syntactic_booleq  =  fun  { cf>  T}  el  e2  => 

8  match  equalchecker_syntactic  ©el  ©e  with 

9  some  _  i— ►  true  |  none  >— *■  false  ; ; 
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letrec  find 

:  ({<^>}-,  h:eufhash_t,  {TiOType}-,  t:0T)  — >  (rep:0T)  X  hol(0t  =  rep) 

=  fun  {<^}  h  {T}-  t  => 

let  add_to_congedges  =  fun  {Tl}  tl  {T2J  t2  => 
let  <  tlrep,  >  =  find  h  @tl  in 
let  (_,  congedges)  =  hashget_f orce  h  ©tlrep  in 
congedges  :=  setadd  ! congedges  @t2 
in 

let  rep_of _funapp 

:  ({T  T’>,  f  :  @T  — >  T’  ,  a  :  @T)  — >  (farep  :  OTOxhoKSf  a  =  farep) 
=  fun  {T  T’}  f  a  =>• 

let  <  frep,  fprf  >  =  find  h  Of  in 
let  <  arep,  aprf  >  =  find  h  0a  in 

if  (syntactic_booleq  Of  Ofrep)  &&  (syntactic_booleq  0a  Oarep)  then 

<  Of  a,  StaticEqual  > 

else  let  <  farep,  faprf  >  =  find  h  (Ofrep  arep)  in 

<  Of arep,  StaticEqual  > 
in 

match  hashget  h  Ot  with 

some  (paredge,  congedges)  •— ► 

let  <  parent,  prf  >  =  ! paredge  in 
if  syntactic_booleq  Ot  ©parent  then  ! paredge 
else  let  <  rep  ,  prf’  >  =  find  h  ©parent  in 
<  ©rep  ,  StaticEqual  > 

I  none  >— »•  let  congedges  =  ref  emptyset  in 
holmatch  Ot  with 

0(f  :  T’  — *■  T)  a  >—>  let  paredge  =  rep_of _funapp  Of  ©a  in 

hashset  h  Ot  (ref  paredge,  congedges); 
add_to_congedges  0a  Ot; 
add_to_congedges  Of  Ot; 
paredge 

I  ©t’’  i— >  let  self edge  =  <  Ot  ,  StaticEqual  >  in 

hashset  h  ©t  (ref  self edge,  congedges); 
selfedge  ; ; 


Code  Listing  9.9:  find  -  Finding  the  equivalence  class  representative  of  a  term 
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let  union  =  fun  {cf>~}  h  =>- 

fun  {T}  tl  t2  (prf  :  Otl  =  t2)  => 
let  <  nlrep,  prfl  >  =  find  h  Otl  in 
let  <  n2rep,  prf2  >  =  find  h  Ot2  in 
if  syntactic_booleq  Otlrep  Ot2rep  then  () 

else  let  (paredgel,  congedgesl)  =  hashget_f orce  h  Otlrep  in 
let  (_,  congedges2)  =  hashget_f orce  h  0t2rep  in 
let  paredgel’  = 

<  0t2rep  ,  StaticEqual  > 

:  (tlpar  :  OT)  xhol (Otlrep  =  tlpar) 
in 

paredgel  :=  paredgel’; 

congedges2  :=  setunion  ! congedgesl  !congedges2; 
congedgesl  :=  emptyset  ;; 


Code  Listing  9.10:  union  -  Merging  equivalence  classes 


let  simple_eq 

:  ({(/>})  — *■  eufhash_t  — *  ({T},  tl,  t2)  —*■  option  hoi (Otl  =  t2) 
=  fun  {(f>J  h  {T}-  tl  t2  =>- 

let  <  tlrep,  prfl  >  =  find  h  Otl  in 
let  <  t2rep,  prf2  >  =  find  h  @t2  in 
holmatch  Otlrep  with 

0t2rep  >— »•  some  StaticEqual 
I  Otlrep’  i— >  none  ;  ; 

let  congruent_eq 

:  —*  eufhash_t  — *  ({T},  tl,  t2)  — >  option  hol(0tl  =  t2) 

=  fun  {cf>J  h  {T}-  tl  t2  =>• 

(simple_eq  h  tl  t2)  | | 
holmatch  Otl,  0t2  with 

0(fl  :  T’  -*  T)  al,  0(f2  :  T’  — >  T)  a2  ^ 
do  <  pff  >  <—  simple_eq  h  Ofl  Of 2; 

<  pfa  >  <—  simple_eq  h  Oal  0a2; 
return  StaticEqual 
I  Otl ’ ,  0t2 ’  i— ►  none 


Code  Listing  9.11:  simple_eq,  congruent_eq  -  Checking  equality  based  on  existing  knowledge 


1  letrec  merge 

2  :  ( cf> )  — >  eufhash_t  ->  (  T,  tl  :  OT,  t2  :  OT  ,  prf  :  Onl  =  n2)  — »  Unit 

3  =  fun  {<^}  h  {T}  tl  t2  H  => 

4  let  mergeifneeded  = 

5  fun  {Tl>  tl  {T2>  t2  =>- 

6  holmatch  0T1  with 

7  0T2  i— *•  let  <  tlrep,  >  =  find  h  Otl  in 

8  let  <  t2rep,  >  =  find  h  0t2  in 

9  if  not  (syntactic_booleq  Otlrep  0t2rep)  then 

10  match  congruent_eq  h  Otl  0t2  with 

11  some  <  prf 2  >  ►  merge  h  Otl  0t2  0prf2 

12  I  none  ►  () 

is  I  0T1  () 

14  in 

is  let  <  tlrep,  >  =  find  h  Otl  in 

16  let  <  t2rep,  >  =  find  h  0t2  in 

17  if  syntactic_iseq  Otlrep  0t2rep  then  () 

is  else  let  (_,  congedgesl)  =  hashget_f orce  h  Otlrep  in 

19  let  (_,  congedges2)  =  hashget_f orce  h  0t2rep  in 

20  union  h  Otl  0t2  Oprf ; 

21  setiter  (fun  Tl  tl  => 

22  setiter  (fun  T2  t2  =>-  mergeifneeded  Otl  0t2) 

23  congedges2) 

24  congedgesl  ;  ; 

Code  Listing  9.12:  merge  -  Incorporating  a  new  equality  hypothesis 


1  let  build_eufhash  :  ( cf>  :  ctx)  — >  eufhash_t  0  =  fun  cf)  => 

2  let  hyplist  =  gather_eq_hyps  0  in 

3  let  eufhash  =  emptyhash  in 

4  listfold 

5  (fun  _  <  {T},  tl,  t2,  prf  :  Otl  =  t2  >  =£- 

6  merge  eufhash  Otl  0t2  Oprf) 

7  ()  hyplist; 

8  eufhash  ; ; 

9 

10  let  equalchecker_euf  :  equalchecker_t  = 

11  fun  {(p  T}  tl  t2  => 

12  let  eufhash  =  build_eufhash  0  in 

13  simple_eq  eufhash  Otl  0t2  ;  ; 

Code  Listing  9.13:  equalchecker_euf  -  Equality  checking  module  for  EUF  theory 
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let  rewriter_beta  :  rewriter_module_t  = 
fun  recursive  {</>  T}  e  =>■ 
holmatch  @e  with 
@(tl  :  T’  — >  T)  t2 

let  <  tl’,  pfl  >  =  recursive  Otl  in 
let  <  e’ ,  pfeJ  >  = 

holmatch  Otl’  as  tl’’ 

return  (  e’  :  OT  )  X  hol(  Otl’’  t2  =  e’  ) 
with 

Ofun  x  :  T’  =>  tlbody  >— > 

<  Otlbody/ [id_</> ,  t2]  ,  ©beta  (fun  x=>tlbody)  t2  > 
I  Otl’’  >— »•  <  Otl’  t2  ,  StaticEqual  > 
in  <  0e’,  StaticEqual  > 

I  (  t  :  @T  )  .  @t  i— ►  <  @t  ,  StaticEqual  >  ;  ; 


Code  Listing  9.14:  Rewriter  module  for  /3-reduction 
and  elimination  points  for  dependent  tuples. 

After  registering  the  EUF  equality  checker  so  that  it  is  always  used,  the  implementation  of  further 
tactics  and  decision  procedures  is  simplified.  It  is  more  robust  than  the  naive  rewriter  presented  earlier, 
so  users  can  rely  on  the  equality  checker  being  able  to  take  equality  hypotheses  into  account  in  most 
cases  where  they  would  help.  For  example,  we  can  use  it  to  write  a  rewriter  module  for  /3-reduction, 
as  presented  in  Code  Listing  9.14.  The  call  to  StaticEqual  in  line  13  relies  on  the  EUF  checker  in 
order  to  discover  the  involved  proof.  The  meta-generation  of  rewriter  modules  for  arbitrary  lemmas  from 
Section  8.3.1,  which  is  used  to  minimize  the  effort  required  to  develop  modules  such  as  rewrite_beta, 
also  emits  code  that  relies  on  the  EUF  checker. 

9.5  Automated  proof  search  for  first-order  formulas 

We  will  shift  our  attention  to  automatically  proving  first-order  formulas  involving  logical  connectives 
such  as  conjunction  and  disjunction.  We  will  present  a  simple  prover  based  on  a  brute-force  strategy  with 
backtracking.  The  main  function  of  the  prover  is  autoprove  in  Code  Listing  9.15;  it  uses  the  function 
f  indhyp  to  find  a  proof  of  a  formula  using  the  current  hypotheses  as  presented  in  Code  Listing  9.16;  and 
it  handles  implications  of  the  form  Pj  — >  P2  through  the  autoprove_with_hyp  function,  presented  in 
Code  Listing  9.17. 

The  autoprove  function  itself  is  straightforward.  It  proceeds  by  pattern  matching  on  the  current 
goal,  proving  conjunctions  by  attempting  to  prove  both  propositions  recursively  and  disjunctions  by 
attempting  to  solve  the  first  and  backtracking  to  solve  the  second  if  that  fails.  Universal  quantification 
starting  in  line  18  uses  the  v  construct  in  order  to  introduce  a  new  logical  variable  in  the  current  <f> 
context,  so  that  we  can  proceed  recursively.  Equality  is  handled  through  the  current  equality  checking 
function.  The  autoprove_with_hyp  function  solves  goals  of  the  form  P1  — *■  P2.  We  separate  it  so  that 
we  can  handle  cases  where  conjunction  or  disjunction  appear  in  P1. 

In  the  default  case,  we  attempt  to  solve  the  goal  using  the  current  hypotheses  directly,  or  by  proving 
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let  autoprove 

:  (  P  :  ©Prop  )  — >  set_t  — *■  option  (hoi (OP)) 

=  fun  {cf>J  P  visited  => 

if  setmember  visited  ©P  then  none 
else 

holmatch  ©P  with 

©PI  A  P2  >-+  do  <  prfl  >  <—  autoprove  ©PI  visited  ; 

<  prf2  >  <—  autoprove  @P2  visited  ; 
return  <  ©andlntro  prfl  prf2  > 

I  ©PI  V  P2  >— 4  (do  <  prfl  >  <—  autoprove  ©PI  visited  ; 

return  <  ©orlntrol  prfl  >  )  | I 
(do  <  prf2  >  <—  autoprove  @P2  visited  ; 
return  <  @orIntro2  prf2  >  ) 

I  ©PI  — *  P2  i— *  autoprove_with_hyp  ©PI  @P2 

I  @Vx  :  A,  P’  i— >■ 

do  <  [  @  ,  x  :  A  ] .prf  >  <—  v  x  :  A  in  autoprove  @P  visited  ; 
return  <  @fun  x  :  A  =>  prf  > 


©True 


some  <  Struelntro  > 


I  @tl  =  t2  def ault_equalchecker  @tl  @t2 

I  @P’  >  let  visited’  =  setadd  visited  @P  in 

(findhyp  ©P  visited’)  || 

(do  <  absurd  >  <—  findhyp  ©False  visited’ 
return  <  ©Falselnd  absurd  >)  | | 
(setremove  visited  OP;  none)  ; ; 

"Auto"  :=  match  autoprove  0  0?  emptyType  with 
some  prf  —4  prf  |  none  —4  error  ; ; 


Code  Listing  9. 15:  autoprove  -  Main  function  for  automated  proving  of  first-order  formulas 
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type  hyplist_t  =  fun  {cf>  :  ctxf  =>-  list  ((  H  :  ©Prop  )  X  hol(  @H  ))  ;; 


let  gatherhyps  :  (<^>)  — >  hyplist_t  = 

fun  cf)  => 
holmatch  ©  with 
[]  i— ►  nil 

I  [  <f) 0  ,  H  :  (P  :  Prop)  ]  ► 

let  ©  =  cf> 0  in 
let  hyps  =  gatherhyps  0  in 
let  <  P’ ,  prfeq  >  =  def ault_rewriter  @P  in 
v  H  :  P  in 

cons  <  ©P’  ,  {{  Exact  H  }}  >  hyps 
I  [  cf>0 ,  t  :  (T  :  Type)  ]  >— >  gatherhyps  cf> 0 
I  [  cf> 0,  t  :  Type]  >— >  gatherhyps  <f> 0  ;; 

let  findhyp 

:  (  {(f>J ,  Goal  :  ©Prop  )  — >  set_t  — *■  option  (hol(  ©Goal  )) 

=  fun  {cf>J  Goal  visited  =>- 
let  hyps  =  gatherhyps  @  in 
listfold 

(fun  curprf  <  Hyp  :  ©Prop,  hyp  :  ©Hyp  >  =>- 
(curprf)  |  | 

(do  <  prfeq  >  <—  def ault_equalchecker  ©Hyp  ©Goal  ; 

return  (Exact  ©hyp) )  I  I 
(holmatch  ©Hyp  with 
@P  — *  Q  >— ► 

do  <  prfeq  >  <—  default_equalchecker  @P— >Q  @P— »Goal  ; 

<  prfP  >  <—  autoprove  @P  visited  ; 
return  (Exact  ©hyp  prf P) )  | | 

(holmatch  ©Hyp  with 
©PI  ->  P2  Q  i-> 

do  <  prfeq  >  <—  default_equalchecker  ©PI— >P2— >Q  ©PI— >P2-^-Goal  ; 

<  prfP  >  «—  autoprove  ©P1AP2  visited  ; 

return  (Exact  ©hyp  (andEliml  prfP)  (andElim2  prfP)))) 

none  1 


Code  Listing  9.16:  f  indhyp  -  Search  for  a  proof  of  a  goal  in  the  current  hypotheses 


1  let  autoprove_with_hyp 

2  : 

3 

. 

5  ©PI  A  P2  >->  do  <  prf  >  <—  autoprove_with_hyp  ©PI  @P2  — *  G  ; 

6  return  <  ©fun  h  =>-  prf  (andEliml  h)  (andElim2  h)  > 

7 

s  I  @P1  V  P2  >— >  do  <  prfl  >  <—  autoprove_with_hyp  ©PI  @G  ; 

9  <  prf2  >  <—  autoprove_with_hyp  @P2  @G  ; 

10  return  <  ©fun  h  =>  orlnd  prfl  prf 2  h  > 

11 

12  I  ©H’  -*• 

13  do  <  [@,  h  :  H]  .g  >  «—  v  h.  :  Hin  autoprove  @G  emptyset  ; 

14  return  <  ©fun  h  =>  g  > 


(  {(f>J ,  H  :  ©Prop,  G  :  ©Prop  )  — *  option  (hol(@H  — *  G)) 
fun  {cf)J  H  G  => 
holmatch  @H  with 


Code  Listing  9.17:  autoprove_with_hyp  -  Auxiliary  function  for  proving  a  goal  assuming  an  extra 
hypothesis 

absurdity  from  the  current  hypotheses.  We  use  the  f  indhyp  function  to  do  this  from  Code  Listing  9.16, 
which  either  tries  to  find  a  hypothesis  that  matches  the  goal  up  to  the  current  equality  checking  relation,  or 
a  hypothesis  that  matches  the  goal  save  for  some  extra  premises.  These  premises  are  then  solved  recursively 
using  autoprove.  In  order  to  avoid  infinite  loops  that  could  arise  from  this  behavior,  we  maintain  a 
set  of  propositions  that  we  have  already  attempted  to  solve  in  the  visited  argument  of  autoprove. 
The  f  indhyp  function  utilizes  the  auxiliary  gatherhyps  function,  which  separates  hypotheses  from  the 
current  (f)  context  and  stores  them  into  a  list  so  that  they  can  be  further  manipulated.  This  is  mostly 
similar  to  gather_eqhyps  as  seen  earlier. 

Using  this  automated  prover  we  can  solve  goals  that  involve  the  basic  first-order  connectives.  For 
example,  the  following  lemma  can  be  proved  automatically  thanks  to  the  logical  reasoning  provided  by 
autoprove  and  the  equality  reasoning  provided  through  equalchecker_euf . 

Lemma  testl  :  Vx,y,z.  (x=yAy=z)  V  (z=yAy=x)  — »  x  =  z  :=  Auto  ;; 


9.6  Natural  numbers 

We  will  now  present  the  VeriML  implementation  of  the  theory  of  natural  numbers  including  the  addition 
and  multiplication  functions,  along  with  their  algebraic  properties.  The  type  of  natural  numbers  is  defined 
as  an  inductive  type  in  dHOL  as  shown  in  Code  Listing  9.18,  lines  1  through  3.  This  definition  generates  a 
number  of  constants  to  perform  elimination  and  induction  on  natural  numbers  following  the  description 
of  Subsection  8.2.2.  Elimination  is  governed  by  the  two  generated  rewriting  lemmas  NatElimzero  and 
NatElimsucc;  we  add  these  to  the  default  equality  checking  procedure  through  rewriter  meta-generation 
as  described  in  Section  8.3.1.  In  this  way  when  using  functions  defined  through  elimination,  such  as 
addition  and  multiplication,  their  result  will  be  computed  during  equality  checking.  These  are  shown  in 
lines  5  through  13. 

We  next  define  a  tactic  that  simplifies  the  use  of  the  natural  number  induction  principle.  We  need  this 
so  that  the  types  of  the  base  and  inductive  cases  do  not  include  j3- redeces  in  the  common  case.  Such  rede- 
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1  Inductive  Nat  :  Type  := 

2  zero  :  Nat 

3  I  succ  :  Nat  — >  Nat  ; ; 

4 

5  (*  generated  constants: 

6  NatElim  :  [T  :  Type]T  — »  (Nat  — »  T  — >■  T)  — >  Nat  — >  T ;  ; 

7  NatElimzero  :  [T  :  Type]Vfz  fs,  NatElim  fz  fs  zero  =  fz; ; 

8  NatFoldsucc  :  [T  :  Type]Vfz  fs  n,  NatElim  fz  fs  (succ  n)  = 

9  f s  n  (NatElim  fz  f s  n) ; ; 

10  Natlnd  :  VP  :  Nat  —*■  Prop,  P  zero  — >  (Vn,P  n  — »  P  (succ  n))  — >  Vn,P  n; ;  *) 

11 

12  global_rewriter_add  (GenerateRewriter  NatElimzero) ; ; 

13  global_rewriter_add  (GenerateRewriter  NatElimsucc) ; ; 

14 

15  let  nat_induction  = 

16  fun  cj)  (P  :  \_cf) ,  x  :  Nat],  Prop) 

it  (pfl  :  hoi  (@P/  [id_<^>  ,0] ) ) 

is  (pf2  :  hol(@Vx  :  Nat,  P/[id_^»,x]  — >  P/[id_^>,  succ  x])) 

io  (spf 1  :  hoi (0?) )  (spf 2  :  hol(@?))  (spf3  :  hol(@?))  =>- 

20  let  <  pfl’  >  =  Exact  pfl  by  spfl  in 

21  let  <  pf2’  >  =  Exact  pf2  by  spf  2  in 

22  (Exact  <  SNatlnd  (fun  x  =>  P)  pfl’  pf2’  >  by  spf 3) 

23  :  hoi (  @Vx  :  Nat,  P  )  ;; 

24 

25  "Natlnduction  for  x.P  base  case  by  el  inductive  case  by  e2"  := 

26  nat_induction  0  (vx  in  @P)  el  e2  StaticEqual  StaticEqual  StaticEqual  ; ; 

Code  Listing  9.18:  Definition  of  natural  numbers  and  natural  induction  tactic 
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ces  arise  in  most  cases  of  using  natural  number  induction  because  the  induction  principle  is  represented 
as  a  Nat  — >  Prop  predicate,  usually  of  the  form  fun  x  =>  P.  The  lack  of  /3-reduction  support  in  the  def¬ 
initional  equality  of  dHOL  means  that  an  application  of  this  predicate  such  as  (fun  x  =>  P)  0  has  to 
be  explicitly  proved  to  be  equal  to  P/  [id,  0] .  The  induction  tactic  uses  the  default  equality  checking 
function  in  order  to  prove  the  equality  between  such  forms,  allowing  the  user  to  consider  the  reduced 
forms  for  the  base  and  inductive  case. 

A  surprising  thing  about  nat_induction  is  that  it  does  not  directly  use  the  StaticEqual  tactic  to 
solve  the  involved  equalities  in  its  code.  The  essential  reason  is  that  the  positions  where  this  tactic  would 
be  used,  in  all  applications  of  the  Exact  tactic,  do  not  fall  under  the  constraints  imposed  by  the  collapsing 
transformation  described  in  Section  5.2:  they  include  non-identity  substitutions  for  the  metavariable  P . 
Thus  this  transformation  cannot  be  directly  used  so  that  ReqEqual  is  called  statically  inside  the  code  of 
nat_ induct  ion.  Yet  we  expect  that  in  most  cases  where  the  induction  tactic  is  used  the  constraints  of 
the  collapsing  transformation  will  indeed  be  satisfied  and  the  involved  proofs  can  be  statically  discovered 
at  those  points.  We  therefore  transfer  the  requirement  for  the  equality  proofs  from  the  place  where 
the  induction  tactic  is  defined  to  all  the  places  where  it  is  used.  Through  suitable  syntactic  sugar,  this 
additional  requirement  is  hidden  from  the  user. 

In  Code  Listing  9.19,  we  present  the  definition  and  algebraic  properties  of  the  natural  number  addi¬ 
tion  function.  The  proofs  of  the  properties  are  mostly  automated  save  for  having  to  specify  the  induction 
principle  used.  The  fact  that  the  induction  principle  has  to  be  explicitly  stated  in  full  stems  from  a  limita¬ 
tion  in  the  type  inference  support  of  the  VeriML  prototype.  The  automation  comes  from  the  extensible 
equality  checking  support:  as  soon  as  a  property  is  proved  it  is  added  to  the  global  default  rewriter,  which 
enables  equality  checking  to  prove  the  required  obligations  for  further  properties.  Thus  by  proving  the 
lemmas  in  the  right  order,  we  can  limit  the  amount  of  the  required  manual  effort.  After  proving  the 
commutativity  and  associativity  properties  of  addition,  we  use  a  generic  commutativity  and  associativity 
equality  module  to  add  them  to  the  global  equality  checking  procedure.  The  type  of  the  generic  module 
is: 

equalchecker_comm_assoc  :  ({T  :  ©Type},  {op  :  @T  — >  T  — >■  T})  — ► 

(op_comm  :  @Vx  y,  op  x  y  =  op  y  x)  — *■ 

(op_assoc  :  @Vx  y  z,op  x  (op  y  z)  =  op  (op  x  y)  z)  — > 
equalchecker_t  ; ; 

We  do  not  give  the  code  of  this  function  here.  It  proceeds  by  pattern  matching  on  terms,  ordering  appli¬ 
cations  of  the  op  argument  (here  instantiated  as  the  addition  function  plus),  based  on  the  hash  values  of 
their  arguments.  It  yields  a  normalized  form  for  terms  that  are  equivalent  up  to  associativity  and  com¬ 
mutativity.  This  function  resembles  the  naive  equality  rewriter  of  Section  9.3  and  suffers  from  similar 
shortcomings:  it  can  only  prove  simple  cases  where  associativity  and  commutativity  apply  and  it  imple¬ 
ments  a  very  inefficient  strategy. 

The  theory  of  multiplication  is  similar  and  is  presented  in  Code  Listing  9.20.  We  have  elided  the 
global  rewriter  registration  calls  for  presentation  purposes;  they  directly  follow  the  addition  case.  The 
main  difference  with  addition  is  that  not  all  proofs  are  automatic:  in  the  theorems  mult_x_Sy  and 
mult_plus_distr,  the  equality  checking  support  is  not  enough  to  prove  the  inductive  case.  We  have 
to  specify  explicitly  that  terms  should  be  rewritten  based  on  the  induction  hypothesis  instead  -  using  a 
tactic  similar  to  the  naive  rewriter  of  Section  9.3,  which  only  rewrites  terms  based  on  a  given  equality 
proof.  To  see  why  this  is  necessary,  consider  the  following  proof  obligation  from  mult_x_Sy,  line  17: 
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1  Definition  plus  :  Nat  — »  Nat  — »  Nat  :=  fun  x  :  Nat  =>  fun  y  :  Nat  => 

2  NatElim  y  (fun  p  r  =>  succ  r)  x  ; ; 

3 

4  Temporary  Rewriter  (Unfolder  plus)  in  { 

5  Theorem  plus_Z_y  :  Vy,0  +  y  =  y  :=  Auto  ; ; 

6  Theorem  plus_Sx_y  :  Vx  y, (succ  x)  +  y  =  succ  (x  +  y)  :=  Auto  ;; 

7  > 

8 

9  global_rewriter_add  (GenerateRewriter  plus_Z_y) ; ; 

10  global_rewriter_add  (GenerateRewriter  plus_Sx_y) ; ; 

11 

12  Theorem  plus_x_Z  :  Vx  :  Nat,  x  +  0  =  x  :  = 

13  Natlnduction  for  x.  x  +  0  =  x 

14  base  case  by  Auto 

15  inductive  case  by  Auto  ;  ; 

16 

17  Theorem  plus_x_Sy  :  V (x  y  :  Nat),  x  +  (succ  y)  =  succ  (x  +  y)  := 
is  Intro  x  y  in 

19  Instantiate 

20  (Natlnduction  for  z.  z  +  (succ  y)  =  succ  (z  +  y) 

21  base  case  by  Auto 

22  inductive  case  by  Auto) 

23  with  @x  ;  ; 

24 

25  global_rewriter_add  (GenerateRewriter  plus_x_Z) ; ; 

26  global_rewriter_add  (GenerateRewriter  plus_x_Sy) ; ; 

27 

28  Theorem  plus_comm  :  V (x  y  :  Nat),  x+y=y+x  := 

29  Intro  x  y  in 

30  Natlnduction  for  y.  x  +  y  =  y  +  x 

31  base  case  by  Auto 

32  inductive  case  by  Auto  ;  ; 

33 

34  Theorem  plus_assoc  :  V (x  y  z  :  Nat),  x  +  (y  +  z)  =  (x  +  y)  +  z  := 

35  Intro  x  y  in 

36  Natlnduction  for  z.x  +  (y  +  z)  =  (x  +  y)  +  z 

37  base  case  by  Auto 

38  inductive  case  by  Auto  ;  ; 

39 

40  global_equalchecker_add  (equalchecker_comm_assoc  plus_comm  plus_assoc)  ; ; 


Code  Listing  9.19:  Addition  for  natural  numbers 
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1  Definition  mult  :  Nat  — »  Nat  — »  Nat  :=  fun  x  :  Nat  =>  fun  y  :  Nat  => 

2  NatElim  0  (fun  p  r  =>  y  +  r)  x  ; ; 

3 

4  Theorem  mult_z_y  :  Vy  :  Nat,  0  *  y  =  0  :=  Auto  ;; 

5  Theorem  mult_Sx_y  :  V (x  y  :  Nat),  (succ  x)  *  y  =  y  +  (x  *  y)  :=  Auto  ;; 

6 

7  Theorem  mult_x_z  :  Vx  :  Nat,  x  *  0  =  0  := 

8  Natlnduction  for  x.  x  *  0  =  0 

9  base  case  by  Auto 

10  inductive  case  by  Auto  ;  ; 

11 

12  Theorem  mult_x_Sy  :  Vx  y,  x  *  (succ  y)  =  x  +  (x  *  y)  := 

13  Intro  x  y  in 

14  Instantiate 

15  (Natlnduction  for  z.  z  *  (succ  y)  =  z  +  (z  *  y) 

16  base  case  by  Auto 

17  inductive  case  by  (  Intro  z  in  Assume  IH  in  Rewrite  @IH  in 

is  Auto  )  ) 

19  with  @x  ;  ; 

20 

21  Theorem  mult_comm  :  Vxy,  x*y  =  y*x  :  = 

22  Intro  x  in 

23  Natlnduction  for  y.  x*y  =  y*x 

24  base  case  by  Auto 

25  inductive  case  by  Auto  ;  ; 

26 

27  Theorem  mult_plus_distr  :  Vx  y  z,  x  *  (y  +  z)  =  (x  *  y)  +  (x  *  z)  := 

28  Intro  x  y  z  in 

29  Instantiate 

30  (Natlnduction  for  a.  a  *  (y  +  z)  =  (a  *  y)  +  (a  *  z) 

31  base  case  by  Auto 

32  inductive  case  by  (  Intro  a  in  Assume  IH  in  Rewrite  @IH  in 

33  Auto  )  ) 

34  with  @x  ;  ; 

35 

36  Theorem  mult_assoc  :  Vx  y  z,  x  *  (y  *  z)  =  (x  *  y)  *  z  := 

37  Intro  x  y  in 

38  Natlnduction  for  z.x  *  (y  *  z)  =  (x  *  y)  *  z 

39  base  case  by  Auto 

40  inductive  case  by  Auto  ;  ; 


Code  Listing  9.20:  Multiplication  for  natural  numbers 
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IH  :  z  *  (succ  y)  —  z  +  (z*y) 

G  :  ( succ  z)  *  ( succ  y)  =  ( succ  z)  +  ({succ  z)*y) 

Equality  checking  proceeds  as  follows.  First  we  rewrite  the  left-hand  side  and  right-hand  side  of  the 
equality  to  normal  form  based  on  the  current  default  rewriter: 

(LHS)  ( succ  z)  *  (succ  y )  — ►  (mult_Sx_y)  (RHS)  (succ  z)  +  ((succ  z)*y)  — >  (plus_Sx_y) 

(succ  y)  +  z  *  (succ  y) — *■  (plus_Sx_y)  succ  (z  +  (succ  z)  *  y) — ►  (mult_Sx_y) 

succ  (y  +  z  *  (succ  y))  succ  (z  +  y  +  z  *  y) 

The  current  equality  checking  cannot  decide  these  two  normal  forms  to  be  equal.  In  order  for  the  EUF 
procedure  to  take  the  induction  hypothesis  into  account,  there  would  need  to  be  an  explicit  z  +  z  *  y 
subterm  in  the  RHS.  Such  a  term  would  only  appear  if  we  rewrite  the  RHS  into  y  +  z  +  z  *y  based  on 
commutativity,  yet  the  naive  commutativity  support  does  not  have  any  sophistication  so  as  to  perform 
this  commutativity  step;  rewriting  into  this  form  would  be  just  a  coincidence  based  on  the  hash  values 
of  the  terms  and  we  should  not  therefore  depend  on  it.  What  we  do  instead  is  to  force  a  rewriting  step 
in  the  LHS  based  on  the  inductive  hypothesis,  resulting  in  the  equivalent  term  succ  (y  +  z  +  z  *y).  Now 
the  naive  commutativity  support  will  rewrite  both  the  LHS  and  RHS  into  the  same  normal  form  and 
syntactic  equality  yields  the  desired  equality  proof. 

The  distributivity  property  of  multiplication  with  regards  to  addition  requires  no  special  provision  in 
terms  of  equality  checking  support;  the  default  meta-generated  rewriter  for  it  is  enough  to  handle  cases 
where  it  needs  to  be  used. 

9.7  Normalizing  natural  number  expressions 

We  will  now  develop  a  more  sophisticated  rewriter  that  normalizes  arithmetic  terms  up  to  associativity 
and  commutativity  of  addition  and  multiplication.  The  rewriter  works  as  follows:  given  an  arithmetic 
term,  it  constructs  a  list  of  monomials  of  the  form  a  ■  x  where  a  is  a  constant  expression  and  %  is  a  variable 
or  a  product  of  variables  (nat_to_monolist  in  Code  Listing  9.23);  the  list  is  sorted  so  that  monomials 
on  the  same  variable  become  adjacent  (sort_list  in  Code  Listing  9.22);  consecutive  monomials  on  the 
same  variable  are  factorized  (f  actorize_monolist  in  Code  Listing  9.24);  and  the  list  of  monomials  is 
converted  back  into  an  arithmetic  expression.  These  auxiliary  functions  need  to  be  partially  correct  so 
that  the  resulting  rewriter  can  prove  that  rewriting  a  term  t  to  t'  based  on  this  sequence  of  steps  is  actually 
valid.  For  example,  the  nat_to_monolist  function  has  to  return  a  monomials  list  that,  when  summed, 
is  equivalent  to  the  original  number;  and  sorting  a  list  of  monomials  needs  to  return  the  same  list,  albeit 
permuted.  Note  that  the  second  property  of  sorting,  namely  the  fact  that  the  returned  list  is  ordered,  is 
not  important  for  our  purposes. 

In  order  to  be  able  to  specify  and  reason  about  the  behavior  of  these  functions,  we  need  a  definition 
of  lists  at  the  level  of  the  logic.  This  is  shown  in  Code  Listing  9.21.  Contrast  this  definition  with  the 
definition  of  lists  at  the  computational  level  of  VeriML,  as  seen  earlier  in  Code  Listing  9.1:  the  logic 
definition  allows  us  to  reason  about  lists,  describing  the  behavior  of  list-related  functions  at  the  logic  or 
computational  level;  whereas  the  computational  definition  allows  us  to  define  lists  of  arbitrary  VeriML 
values,  including  mutable  references  and  contextual  terms  but  precludes  reasoning  about  their  behavior. 
The  effort  associated  with  having  to  duplicate  definitions  can  be  mitigated  by  having  logic  definitions 
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1  Inductive  List  [  T  :  Type  ]  :  Type  := 

2  nil  :  List 

3  I  cons  :  T  — >  List  — >  List  ;  ; 

4 

5  Definition  append  [T  :  Type]  :  List/[T]  — >  List/[T]  — »  List/[T]  :  = 

6  fun  x  y  =>  ListElim  y  (fun  hd  tl  r  =>-  cons  hd  r)  x  ;  ; 

7 

8  Definition  sumlist  :  List/ [Nat]  — >  Nat  := 

9  ListElim  0  (fun  hd  tl  r  =>-  hd  +  res)  ;  ; 

10 

11  Lemma  sum_append  :  Vll  12, 

12  sumlist  (append  11  12)  =  (sumlist  11)  +  (sumlist  12) 

13 

14  Inductive  removed  [T  :  Type]  :  List/[T]  — ►  T  — ►  List/[T]  — ►  Prop  :  = 

is  removedHead  :  Vhd  tl,  removed  (cons  hd  tl)  hd  tl 

16  I  removedTail  :  Velm  hd  tl  tl’,  removed  tl  elm  tl’  — * 

17  removed  (cons  hd  tl)  elm  (cons  hd  tl’)  ;; 

18 

19  Lemma  removed_sum  :  Vl  elm  1’, 

20  removed  1  elm  1’  — »  sumlist  1  =  elm  +  (sumlist  1’) 

21 

22  Inductive  permutation  [T  :  Type]  :  List/[T]  — »  List/[T]  — »  Prop  :  = 

23  permutationNil  :  permutation  nil  nil 

24  |  permutationCons  :  Vhd  11’  12  12’,  removed  12  hd  12’  — > 

25  permutation  11’  12’  — > 

26  permutation  (cons  hd  11’)  12  ;; 

27 

28  Theorem  permutation_sum  :  Vll  12, 

29  permutation  11  12  — *  sumlist  11  =  sumlist  12 

30 

31  Lemma  permutation_removed  [T  :  Type]  :  Vll  elm  11’  12’, 

32  removed  11  elm  11’  — >  permutation  11’  12’  — * 

33  permutation  11  (cons  elm  12’) 

34 

35  Theorem  permutation_symm  [T  :  Type]  :  Vll  12, 

36  permutation  11  12  — >  permutation  12  11 

Code  Listing  9.21:  Definition  of  lists  and  permutations  in  dHOL,  with  associated  theorems 
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implicitly  define  the  equivalent  computational  versions  as  well. 

In  Code  Listing  9.21  we  also  give  the  definitions  of  the  append  function  at  the  logical  level  and  of 
sumlist  which  accumulates  together  the  members  of  lists  of  natural  numbers.  We  also  define  the  predi¬ 
cate  of  a  list  being  a  permutation  of  another,  as  well  as  the  auxiliary  predicate  removed  11  elm  1 1 1 .  This 
stands  for  the  property  “if  the  element  elm  is  removed  from  the  list  11,  the  resulting  list  is  11  ’  ”.  Last,  we 
give  statements  of  lemmas  about  the  interaction  of  these  functions.  We  do  not  give  the  proofs  here;  these 
follow  the  ideas  presented  so  far.  The  proof  that  presents  the  most  difficulty  is  the  permutation_symm 
theorem,  taking  50  lines  in  total.  It  requires  proving  an  inversion  lemma  for  permutations  and  a  number 
of  manual  proof  steps.  This  proof  could  be  significantly  improved  by  meta-generation  of  inversion  prin¬ 
ciples,  as  well  as  the  development  of  automation  for  user-defined  predicates  following  the  ideas  presented 
for  the  equality  predicate;  we  leave  these  matters  to  future  work. 

In  Code  Listing  9.22  we  present  the  sorting  function  for  lists.  This  is  a  computational  function  that 
manipulates  logical  lists.  The  reason  behind  this  choice  is  that  we  want  to  sort  lists  based  on  the  hash 
of  their  elements  -  that  is,  based  on  an  extra-logical  operation  yet  we  also  need  a  proof  that  sorting 
returns  a  permutation  of  the  original  list  -  therefore  the  choice  of  logical  lists.  We  leave  the  comparison 
operation  as  a  parameter  to  the  sorting  function.  The  sorting  algorithm  we  implement  is  selection  sort; 
we  use  the  auxiliary  function  min  list  to  remove  the  minimum  element  of  a  list.  In  both  functions  we 
provide  manual  proofs  of  most  obligations,  using  the  definitions  and  lemmas  of  Code  Listing  9.21.  A 
point  worth  mentioning  is  that  we  need  to  explicitly  rewrite  the  input  lists  to  head-normal  form  before 
pattern  matching  is  performed,  as  matching  happens  only  up  to  syntax  and  not  up  to  /^-equivalence  or 
evaluation  of  logical  functions  such  as  append. 

The  rest  of  the  code  for  arithmetic  simplifications  is  presented  in  Code  Listing  9.23  and  9.24,  following 
the  description  given  earlier.  Sorting  of  monomial  lists  is  done  using  the  comparison  function  cmp.  This 
function  only  uses  the  hash  value  of  the  variable  component  x,  thus  making  monomials  on  the  same 
variable  adjacent  in  the  sorted  list.  It  is  worth  noting  that  most  of  the  proof  obligations  for  these  functions 
are  solved  automatically  for  the  most  part  -an  additional  hint  is  required  in  some  cases-  and  are  validated 
statically  following  the  ideas  we  have  seen  earlier. 

9.8  Evaluation 

This  concludes  our  presentation  of  the  examples  we  have  implemented  in  VeriML.  It  is  worth  noting 
that  the  full  code  of  the  examples  mentioned  above  is  about  1.5k  lines  of  VeriML  code,  including  all  the 
infrastructure  and  basic  library  code  we  describe.  We  offer  a  breakdown  of  the  line  counts  for  the  different 
modules  in  Table  9.1.  In  the  same  table  we  note  the  line  counts  for  the  proof-related  aspects  of  the  code, 
which  include  all  logic  definitions,  proofs,  hints  (as  additions  of  meta-generated  rewriters)  and  induction 
tactics,  in  order  to  give  an  accurate  portrayal  of  the  dHOL-related  reasoning  that  the  programmer  has  to 
do.  It  is  worth  noting  that  the  vast  majority  of  the  proof-related  code  corresponds  to  defining  and  proving 
the  theory  of  natural  numbers,  lists  and  permutations.  The  actual  conversion  implementation  functions 
have  minimal  manual  proof  involved. 

It  is  worth  contrasting  these  line  counts  with  the  two  tactics  in  Coq  that  are  roughly  equivalent  in 
functionality  to  our  implementation  of  the  EUF  and  arithmetic  simplification  conversion  rules,  namely 
congruence  and  ring_simplify  respectively.  This  comparison  is  shown  in  Table  9.2.  For  EUF  con¬ 
version  in  VeriML,  we  have  included  the  naive  equality  rewriter  as  well  as  the  main  EUF  module;  for 
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1  letrec  min_list 

2  :  ({cf)  :  ctx},  {T  :  ©Type},  cmp  :  (@T)  — ►  (@T)  — »  bool,  1  :  ©List)  — * 

3  (min  :  ©T)  X  (rest  :  ©List)  X  hoi  (©removed  1  min  rest) 

4  =  fun  {cf>  T}  cmp  1  => 

5  let  <  @1’  ,  ©pfl’  >  =  def ault_rewriter  @1  in 

6  let  <  ©min,  ©rest,  ©pf  >  = 

7  holmatch  @1’  with 

8  ©nil  i— ►  error 

9  I  ©cons  hd  nil  >— *■  <  @hd  ,  ©nil  ,  ©removedHead  ?  ?  > 

10  I  ©cons  hd  tl  •— ► 

11  let  <  min’ ,  rem,  pf  >  =  min_list  cmp  ©tl  in 

12  if  (cmp  ©hd  ©min’  )  then 

13  <  ©hd  ,  ©tl.  Exact  ©removedHead  hd  tl  > 

14  else 

15  <  ©min’ ,  ©cons  hd  rem,  ©removedTail  pf  > 

16  in  <  ©min  ,  ©rest  ,  {{  Auto  }}  >  ;  ; 

17 

18 

19  let  sort_list 

20  :  ({c f>  :  ctx},  {T  :  ©Type},  cmp  :  (@T)  — >  (@T)  — >  bool,  1  :  ©List)  — * 

21  (1’  :  ©List)  X  hoi  (©permutation  1  1’) 

22  =  fun  {(f>  T}  cmp  1  => 

23  let  <  lnorm  ,  pflnorm  >  =  def ault_rewriter  @1  in 

24  let  <  1’  ,  pfl’  ,  u  >  = 

25  holmatch  ©lnorm  with 

26  ©nil  i— ►  <  ©nil  ,  ©permutationNil  > 

27  I  ©cons  hd  tl  i— ► 

28  let  <  newhd,  newtl,  prfl  >  =  min_list  cmp  (©cons  hd  tl)  in 

29  let  <  newtl’,  prf2  >  =  sort_list  cmp  ©newtl  in 

30  let  <  prf2’  >  =  <  @permutation_symm  prf2  >  in 

31  <  ©cons  newhd  newtl’  , 

32  @permutation_symm  (permutationCons  prfl  prf2’)  > 

33  in  <  ©1’,  {{  Auto  }}  >  ; ; 


Code  Listing  9.22:  Selection  sorting  for  lists 
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1 


let  is_const  =  fun  {phi}-  n  =>- 
2  holmatch  On  with  Oconst/[]  >— *■  true  |  @n’ ’  false  ;; 


3 

4 

5 


7 


10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 
21 
22 

23 

24 

25 

26 

27 

28 

29 

30 


let  nat_to_monolist 

:  {{cf)  :  ctx}  ,  n  :  ONat)  —*■  (  1  :  ©List  )  X  hol(  On  =  sumlist  1  )  ;; 

=  fun  {cf>J  n  =>  holmatch  On  with 
Oa  +  b  i— > 

let  <  11,  pfl  >  =  nat_to_monolist  Oa  in 
let  <  12,  pf2  >  =  nat_to_monolist  Ob  in 
<  ©append  11  12  ,  {{  Cut  ©sum_append  11  12  in  Auto  }}  > 

I  Oa  *  b  i— > 

if  is_const  Oa  kk  is_const  Ob  then 

<  ©cons  ((a  *  b)  *  1)  nil  ,  {{  Auto  }}  > 
else  if  is_const  Oa  then 

<  ©cons  (a  *  b)  nil  ,  {{  Auto  }}  > 
else  if  is_const  ©b  then 

<  ©cons  (b  *  a)  nil  ,  {{  Auto  }}  > 
else 

<  ©cons  (1  *  (a  *  b))  nil  ,  {{  Auto  }}  > 

I  Oe  i— »■  if  is_const  Oe  then 

<  ©cons  (e  *  1)  nil  ,  {{  Auto  }}  > 
else 

<  ©cons  (1  *  e)  nil  ,  {{  Auto  }}  >  ;  ; 

let  cmp  =  fun  <f>  el  e2  =>- 
holmatch  ©el,  @e2  with 

@al  *  bl,  @a2  *  b2  >— »•  (  hash  ©bl  )  <  (  hash  @b2  ) 

I  ©el  ,  @e2  i— ►  (  hash  ©el  )  <  (  hash  @e2  ) 


Code  Listing  9.23:  Rewriter  module  for  arithmetic  simplification  (1/2) 
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1  let  f actorize_monolist 

2  :  {{cf)  :  ctxf,  1  :  ©List)  — *■  (1’  :  ©List)  X  hol(  ©sumlist  1  =  sumlist  1’  ) 

3  =  fun  {<f>  n}  1  =>  holmatch  @1  with 

4  ©cons  (hda  *  hdb)  tl  ► 

5  let  <  tl’  ,  pftl’  >  =  factorize_monolist  ©tl  in 

6  holmatch  ©tl’  with 

7  ©cons  (hdc  *  hdb)  tl,}  >— »• 

8  <  ©cons  ((hda  +  hdc)  *  hdb)  tl’’  , 

9  {{  Rewrite  ©pftl’  in  ReqEqual  }}  > 

10  I  ©tl’  i— ►  <  ©cons  (hda  *  hdb)  tl’  ,  StaticEqual  > 

11  |  @1  h  <  @1  ,  StaticEqual  >  ;  ; 

12 

13  let  rewriter_arithsimpl  :  rewriter_module_t  = 

14  fun  recursive  {<f>  Tf  e  =>- 

15  holmatch  @e  with 

16  ©el  +  e2  >— > 

17  let  <  10,  pfl  >  =  nat_to_monolist  @el+e2  in 

is  let  <  11,  pf2  >  =  sort_list  cmp  @10  in 

19  let  <  12,  pf3  >  =  f actorize_monolist  @11  in 

20  <  ©sumlist  12,  {{  Cut  @permutation_sum  10  11  in  Auto  }}  > 

21  |  @e  i— ►  <  @e  ,  StaticEqual  >  ;  ; 


Code  Listing  9.24:  Rewriter  module  for  arithmetic  simplification  (2/2) 


Basic  library 

Basic  connectives 

Basic  rewriting  support 

Naive  equality  rewriter 

Hash  tables  and  sets  (Prop  and  Type) 

EUF  rewriter 

/3-rewriting 

Auto  prover 

Naive  comm./assoc.  rewriting 
Force  rewriting  on  hypothesis 
Theory  of  natural  numbers 
Lists,  permutations  and  sorting 
Arithmetic  simplification 

Full  code  involved 


Logic  definitions, 
Total  lines  of  code  proofs,  hints 


131 

16 

36 

36 

191 

19 

79 

2 

69x2=138 

0 

200 

0 

21 

1 

178 

14 

111 

17 

56 

7 

128 

128 

200 

158 

84 

3 

1581 

401 

Table  9.1:  Line  counts  for  code  implemented  in  VeriML 
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Total  code  Manual  proof 


VeriML 

EUF  conversion 

279 

2 

Arithmetic  simplification 

395 

178 

Natural  numbers  theory 

128 

128 

Coq 

Congruence 

1437 

62 

Ring  simplification 

1997 

846 

Abstract  ring  theory 

259 

259 

Table  9.2:  Comparison  of  line  counts  for  EUF  rewriting  and  arithmetic  simplification  between  VeriML 
and  Coq 

arithmetic  simplification,  we  have  included  the  naive  commutativity  and  associativity  rewriter,  the  the¬ 
ory  of  lists  and  the  arithmetic  simplification  procedure.  In  both  of  these  cases  some  of  the  code  is  reusable: 
e.g.  the  theory  of  lists  consists  of  theorems  that  are  useful  independently  of  arithmetic  simplification,  and 
the  code  of  the  naive  rewriter  is  mostly  reused  for  implementing  the  forced  rewriting  procedure.  In  com¬ 
puting  the  line  counts  for  the  Coq  versions,  we  have  manually  isolated  the  proof-related  lines,  such  as 
calls  to  tactics  and  CIC  constructors  inside  ML  code  in  the  case  of  the  congruence  tactic,  and  the  lemmas 
proved  using  LTac  proof  scripts  in  the  case  of  ring  simplification.  In  the  same  table,  we  have  also  included 
the  counts  for  our  development  of  the  theory  of  natural  numbers,  as  well  as  the  theory  of  abstract  rings 
used  by  ring_simplify  which  are  composed  of  roughly  the  same  theorems. 

The  VeriML  versions  of  the  tactics  and  proofs  compare  favorably  to  their  Coq  counterparts;  it  is 
telling  that  the  manual  proofs  required  for  all  of  our  VeriML  code,  including  basic  logic  definitions  and 
tactics,  is  half  the  size  of  the  proofs  required  just  for  arithmetic  simplification  in  Coq.  In  arithmetic  sim¬ 
plification,  the  Coq  proofs  are  about  5  times  larger  than  their  VeriML  equivalent;  in  the  EUF  procedure, 
the  ratio  is  30:1,  or  3:1  if  we  include  the  basic  rewriting  support  code  of  VeriML  (which  is  what  accounts 
for  the  congruence  properties).  The  main  reason  behind  the  significant  reduction  in  manual  proof  size  for 
the  VeriML  versions  is  the  way  we  implement  our  proofs  and  proof-producing  functions,  making  use  of 
the  extensible  conversion  support.  As  for  the  overall  reduction  in  code  size,  the  main  reason  is  that  we  do 
not  have  to  go  through  encodings  of  logical  terms  such  as  the  ones  used  by  proof-by-reflection  or  transla¬ 
tion  validation,  as  required  by  the  Coq  versions,  but  can  rather  work  on  the  exact  terms  themselves.  Of 
course  the  comparison  of  line  counts  for  the  programming  aspect  of  the  procedures  cannot  provide  accu¬ 
rate  grounds  for  drawing  conclusions.  This  is  especially  true  since  the  compared  tactics  are  for  different 
logics,  use  more  realistic  and  full-featured  implementations  of  the  algorithms  we  describe  (e.g.  congruence 
takes  injectivity  of  constructors  into  account)  and  the  performance  is  not  yet  comparable,  owing  largely 
to  our  prototype  VeriML  implementation.  Still,  the  difference  in  manual  proof  effort  required  indicates 
the  savings  that  VeriML  can  offer. 
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Chapter  10 

Related  work 


There  is  a  large  body  of  existing  related  literature  that  the  work  in  this  dissertation  rests  upon.  The  design 
of  VeriML  is  such  that  it  can  be  viewed  as  either  a  programming  language  tailored  to  tactic  programming 
or  as  a  complete  proof  assistant.  We  will  therefore  compare  VeriML  to  other  tactic  development  method¬ 
ologies  as  well  as  existing  architectures  of  proof  assistants.  When  viewed  as  a  programming  language,  the 
core  departure  of  VeriML  from  traditional  functional  programming  languages  such  as  ML  and  Haskell  is 
the  availability  of  constructs  for  type-safe  manipulation  of  an  object  language;  we  will  present  a  number 
of  existing  language  designs  that  contain  similar  constructs.  Last,  VeriML  represents  a  particular  way  of 
combining  a  logic  with  a  side-effectful  programming  language,  where  a  strong  separation  between  the  two 
languages  is  maintained.  We  will  compare  this  approach  with  other  potential  combinations. 

10.1  Development  of  tactics  and  proof  automation 

Tactic  development  in  ML.  Most  modern  proof  assistants,  such  as  HOL  [Slind  and  Norrish,  2008, 
Harrison,  1996],  Isabelle  [Paulson,  1994],  Coq  [Barras  et  ah,  2012]  andNuPRL  [Allen  et  ah,  2000],  allow 
users  to  extend  the  set  of  available  tactics,  by  programming  new  tactics  inside  the  implementation  language 
of  the  proof  assistant.  In  all  cases  this  language  is  a  dialect  of  Standard  ML  [Milner,  1997],  In  fact,  ML 
was  designed  precisely  for  this  purpose  in  the  context  of  the  original  LCF  system  [Gordon  et  ah,  1979] 
-  as  the  Meta  Language  of  the  system,  used  to  manipulate  the  terms  of  the  logic  -  the  object  language. 
Developing  tactics  in  ML  is  thus  the  canonical  methodology  used  in  the  direct  descendants  of  this  system 
such  as  HOL. 

The  programming  constructs  available  in  ML  were  chosen  specifically  with  tactic  development  in 
mind,  making  the  language  well-suited  to  that  purpose.  For  example,  higher-order  functions  are  available 
so  that  we  can  define  tacticals  -  functions  that  combine  other  tactics  (which  are  functions  themselves). 
The  programming  model  available  in  ML  is  very  expressive,  allowing  general  recursion,  mutable  refer¬ 
ences  and  other  side-effectful  operations;  this  enables  the  development  of  efficient  tactics  that  make  use  of 
sophisticated  algorithms  and  data  structures  such  as  discrimination  nets  [Gordon,  2000], 

The  main  problem  with  tactic  development  in  ML  is  that  it  is  essentially  untyped.  Logical  terms  and 
proofs  are  encoded  within  ML  as  algebraic  data  types.  Data  types  are  simply-typed  in  ML,  effectively 
identifying  all  proofs  and  all  terms  at  the  level  of  types  and  precluding  any  extra  information  -  such  as 
the  context  of  free  variables  they  depend  on,  or  the  kinds  of  terms,  or  the  consequence  of  proofs  -  from 
being  available  statically.  This  hurts  the  composability  of  tactics  and  their  maintainability  as  well,  as 
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we  cannot  give  precise  signatures  to  the  kinds  of  arguments  they  expect,  the  results  they  produce  and  the 
relationships  between  them.  VeriML  can  be  viewed  as  a  dependently-typed  extension  of  ML  that  addresses 
this  shortcoming,  by  making  the  type  of  proofs  and  logical  terms  dependent  on  the  information  produced 
by  the  type  system  of  the  logic.  The  relationship  between  programming  tactics  in  VeriML  instead  of  ML 
is  therefore  similar  to  the  relationship  of  developing  functional  programs  in  ML  instead  of  Lisp. 

For  example,  the  VeriML  type  we  gave  to  rewriters  is  the  following: 

{(f> :  ctx,  T  :  Type ,  t :  T)  —*■  {t' :  T)  x  (t  =  t ') 

In  ML,  the  equivalent  type  would  be: 

holterm  — >•  holterm  X  holproof 

In  this  type,  the  fact  that  the  input  and  output  terms  share  the  same  type  and  variable  context,  as  well 
as  the  fact  that  the  output  proof  witnesses  the  equivalence  between  the  input  and  output  terms  is  lost. 
Still,  the  types  holterm  and  holproof  have  equivalent  types  in  VeriML,  constructed  by  hiding  the  extra 
context  and  typing  information  through  existential  packages:  the  types  (<f>  :  ctx,  T  :  Type)  X  {t  :  T)  and 
{(f)  :  ctx,P  :  Prop )  X  {p  :  P),  respectively.  This  shows  that,  in  principle,  any  tactic  written  in  ML  for  an 
LCF-style  proof  assistant  can  be  written  as  a  VeriML  function  instead. 

Another  shortcoming  of  ML  in  terms  of  tactic  development  is  that  users  have  to  master  the  internal 
representation  of  logical  terms  and  proofs  in  the  proof  assistant.  For  examples,  the  user  needs  to  know  the 
details  of  how  logical  variables  are  encoded  through  deBruijn  indices  in  order  to  develop  tactics  that  deal 
with  open  terms.  This  can  be  somewhat  mitigated  through  proper  syntactic  extensions  to  ML  as  done  in 
HOL-Light  [Harrison,  1996],  The  first-class  constructs  for  pattern  matching  over  open  logical  terms  and 
contexts  make  tactic  development  in  VeriML  more  convenient,  hiding  the  implementation  details  of  the 
proof  assistant. 

Tactic  development  in  LTac.  The  Coq  proof  assistant  offers  the  higher-level  LTac  language  [Delahaye, 
2000,  2002],  which  is  specifically  designed  for  tactic  development.  This  is  a  significant  feature,  as  it  enables 
users  to  extend  the  provided  automation  with  their  own  tactics  through  convenient  pattern-matching 
constructs,  addressing  the  above-mentioned  shortcoming  of  tactic  development  in  ML.  LTac  has  been  put 
to  good  use  in  various  developments  where  the  manual  proof  effort  required  is  reduced  to  a  minimum  [e.g. 
Chlipala,  2011,  Morrisett  et  ah,  2012],  The  key  construct  of  LTac  is  the  support  for  pattern  matching  on 
proof  states  with  backtracking.  It  is  used  to  examine  the  forms  of  the  current  hypotheses  and  the  current 
goal  and  to  issue  the  corresponding  tactics;  upon  failure  of  such  tactics,  LTac  implicitly  backtracks  to  an 
alternative  pattern  matching  case  allowing  further  progress.  The  pattern  matching  construct  of  VeriML 
has  been  influenced  by  LTac;  it  is  similar  in  features,  save  for  the  backtracking  support  which  we  have 
chosen  to  leave  as  a  user-defined  feature  instead. 

Other  than  the  pattern  matching  construct,  LTac  is  an  untyped  functional  language  without  support 
for  ML -style  data  types  or  side-effects  such  as  mutability.  This  hurts  expressivity,  prompting  users  to  use 
ad-hoc  idioms  to  overcome  the  limited  programming  model  of  LTac.  In  order  to  write  more  sophisticated 
tactics  such  as  congruence  closure,  one  has  to  revert  to  ML.  Also,  LTac  is  interpreted,  leading  to  long 
running  times  for  large  tactics.  Last,  the  untyped  nature  of  the  language  makes  LTac  tactics  notoriously 
hard  to  maintain  and  debug  and  are  sometimes  avoided  precisely  for  this  reason  [e.g.  Nanevski  et  ah, 
2010],  VeriML  addresses  these  shortcomings  by  offering  an  expressive  type  system,  a  full  programming 
model  and  compilation  through  translation  to  ML;  it  can  thus  be  seen  as  a  ‘typed  LTac’. 
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Proof  by  reflection.  Coq  offers  another  methodology  for  writing  user-defined  tactics,  enabled  by  the 
inclusion  of  the  conversion  rule  in  its  logic.  This  rule  renders  the  logic  (referred  to  as  Gallina)  into 
a  functional  programming  language.  For  reasons  of  soundness,  programs  in  this  language  need  to  be 
terminating.  Through  the  technique  of  proof  by  (computational)  reflection  [Boutin,  1997],  we  can  program 
the  decision  procedures  directly  in  the  logic  language.  The  technique  consists  of  reflecting  part  of  the 
propositions  of  the  logic  as  an  inductive  type  within  the  logic  itself,  so  that  they  can  be  manipulated  as 
a  normal  datatype.  Also,  we  need  to  define  encoding  and  decoding  functions  from  propositions  to  the 
inductive  type  and  back.  The  decision  procedure  can  then  be  programmed  as  a  function  at  the  level  of 
the  logic  and  its  correctness  can  be  stated  and  proved  as  a  normal  theorem,  using  the  interactivity  support 
of  Coq.  A  sketch  of  the  different  components  involved  in  the  proof-by-reflection  approach  would  be  as 
follows  using  VeriML -style  types: 

Inductive IProp  :  Type  :=IAnd  ipl  ip2  \  IOr  ipl  ip2  |  •••  . 
encode  :  Prop  — *■  IProp  (programmed  in  LTac) 
decode  :  IProp  — *  Prop  (programmed  in  Gallina) 
decision_procedure  :  IProp  — >  Bool  (programmed  in  Gallina) 
correctness  :  V  ip  : /Prop.decision_procedure  ip  =  true-^>  decode  ip 

In  VeriML,  the  first  three  components  would  not  be  needed  because  we  can  manipulate  propositions 
directly;  and  we  can  write  a  single  function  that  combines  the  last  two  components: 

decision_procedure  :  ( P  :  Prop)  —*■  option  (P) 

The  fact  that  the  decision  procedures  written  in  proof-by-reflection  style  are  certified  means  that  the 
procedures  do  not  need  to  generate  proof  objects;  thus  procedures  written  in  this  style  are  very  efficient. 
Together  with  the  fact  that  Gallina  functions  are  total,  decision  procedures  that  are  complete  for  certain 
theories  do  not  even  need  to  be  evaluated;  their  definition  and  soundness  proof  is  enough  to  prove  all 
related  theorems  directly.  This  fact  has  prompted  Pollack  [1995]  to  propose  total  and  certified  decision 
procedures,  developed  using  a  mechanism  similar  to  proof-by-reflection,  as  the  main  extensibility  mecha¬ 
nism  for  proof  assistants;  yet  this  proposal  has  not  been  followed  through. 

The  main  problem  with  this  approach  is  that  it  has  a  high  up-front  cost  for  setting  up  the  reflection,  es¬ 
pecially  if  we  want  our  decision  procedure  to  manipulate  open  terms:  a  concrete  deBruijn  representation 
must  be  used  for  representing  variables  and  the  user  must  also  develop  functions  to  manipulate  this  rep¬ 
resentation.  Pattern  matching  over  such  encodings  is  cumbersome  compared  to  the  first-class  constructs 
offered  by  LTac  or  VeriML.  Also,  the  programming  model  of  Gallina  does  not  support  side-effects  in  the 
code  of  the  decision  procedures.  In  VeriML  we  can  code  similar  procedures  which  are  also  certified,  yet 
the  total  correctness  requirement  is  relaxed:  VeriML  procedures  can  still  fail  to  terminate  successfully, 
so  they  need  to  be  evaluated  to  completion.  This  is  a  limitation  compared  to  proof-by-reflection,  as  it 
increases  the  required  run  time;  but  it  can  also  be  viewed  as  an  advantage,  as  we  do  not  have  to  prove 
termination  of  the  decision  procedures.  Non-terminating  behavior  is  not  necessarily  a  problem  and  can 
be  used  towards  good  effect  in  our  developments  (e.g.  consider  the  naive  equality  rewriter  of  Section  9.3, 
which  is  non-terminating  in  some  cases).  In  other  cases,  a  procedure  is  terminating  yet  its  termination  cri¬ 
terion  might  be  difficult  to  prove.  In  proof-by-reflection,  the  totality  requirement  has  to  be  circumvented 
through  the  use  of  an  argument  that  limits  the  amount  of  steps  that  are  performed.  Also,  the  certification 
of  VeriML  procedures  is  more  light-weight  than  proof  by  reflection:  the  type  system  of  VeriML  can  be 
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viewed  itself  as  a  light-weight  certification  mechanism.  Coupled  with  the  support  for  static  proof  expres¬ 
sions  to  solve  the  required  proof  obligations  inside  procedures,  this  significantly  limits  the  manual  proof 
effort  required. 

Still,  the  proof-by-reflection  technique  can  be  used  in  the  context  of  VeriML,  which  could  potentially 
be  useful  in  large  developments.  In  fact  VeriML  offers  benefits  for  programming  the  LTac  components  of 
the  proof-by-reflection  procedures.  For  example,  we  could  assign  the  following  rich  type  to  the  encoding 
function: 

encode  :  (P  :  Prop)  —*■  (/  :  IProp)  x  ( decode  I  =  P) 

Also,  the  small-scale  automation  mechanism  used  to  implement  proof-by-reflection,  namely  the  conver¬ 
sion  rule,  is  programmed  directly  in  VeriML  as  well,  leading  to  a  smaller  trusted  base. 

Yet  the  unique  characteristic  of  the  proof-by-reflection  approach  is  that  the  tactics  are  themselves 
logical  functions.  Therefore  we  can  reason  about  them  using  the  full  features  of  the  logic,  allowing  us 
to  prove  deep  theorems  about  their  behavior.  Together  with  the  fact  that  Gallina  has  an  infinite  type 
hierarchy  with  computation  allowed  at  any  level,  this  would  allow  us  to  give  very  precise  signatures  to 
tactics  -  e.g.  capturing  precisely  the  set  of  cases  where  an  automation  tactic  can  be  applied  successfully. 
In  contrast,  VeriML  maintains  a  two-layer  architecture,  where  tactics  are  written  in  the  computational 
language  and  cannot  be  reasoned  about  in  the  logic.  Thus  the  signatures  that  we  can  give  to  tactics  are 
limited  to  what  is  allowed  by  the  VeriML  type  system.  In  the  future  we  would  like  to  explore  the  potential 
of  offering  VeriML  as  a  surface  language  in  a  proof  assistant  such  as  Coq,  where  VeriML -defined  tactics 
are  compiled  down  to  Gallina  tactics  through  proof-by-reflection.  This  is  an  interesting  alternative  that 
offers  some  of  the  benefits  of  both  approaches:  the  up-front  cost  of  setting  up  proof-by-reflection  would 
be  significantly  reduced,  but  we  could  also  reason  about  VeriML  tactics  in  the  logic.  Still,  the  tactics  would 
not  be  able  to  use  side-effects  and  an  efficient  evaluation  strategy  for  the  conversion  rule  (e.g.  compilation- 
based)  would  need  to  be  part  of  the  trusted  base  of  the  system. 

Unification-based  automation.  Coq  includes  another  small-scale  automation  mechanism  other  than 
the  conversion  rule:  a  unification-based  type  inference  engine  used  to  elaborate  surface-level  terms  to  con¬ 
crete  CIC  terms.  By  issuing  hints  to  this  engine,  users  can  perform  automation  steps  as  part  of  type 
inferencing.  The  hints  take  the  form  of  Prolog-like  logic  programs.  Gonthier  et  al.  [2011]  show  how 
these  hints  can  be  encoded  through  the  existing  Coq  mechanism  of  canonical  structures  (a  generalization 
of  type  classes);  also,  the  experimental  Matita  proof  assistant  includes  explicit  support  for  these  unification 
hints  [Asperti  et  al.,  2009],  This  technique  offers  various  advantages  over  untyped  LTac-style  automation 
tactics:  Automation  procedures  are  essentially  lemmas  whose  premises  are  transparently  resolved  through 
unification.  Therefore  we  can  specify  and  develop  the  main  part  of  the  automation  lemmas  by  using  the 
existing  infrastructure  of  the  proof  assistant  for  proving  lemmas.  Also,  since  the  technique  is  based  on  a 
small-scale  automation  mechanism,  automation  developed  in  this  way  applies  transparently  to  the  user, 
allowing  us  to  omit  unnecessary  details. 

The  limitations  of  this  approach  are  that  automation  procedures  need  to  be  written  in  the  logic  pro¬ 
gramming  style  instead  of  a  more  natural  functional  programming  model.  Also,  procedures  written  in 
this  way  are  hard  to  debug,  as  missing  or  erroneous  hints  can  result  in  unspecified  behavior  depending  on 
how  the  type  inferencing  engine  works.  Also  the  support  for  writing  this  style  of  procedures  in  Coq  is 
still  rudimentary  and  requires  ad-hoc  usage  patterns  and  a  high  up-front  cost.  Our  approach  to  extensible 
small-scale  automation  allows  for  more  sophisticated  procedures  that  use  a  full  programming  model.  Still, 
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the  unification-based  approach  is  useful  in  cases  other  than  proof  automation,  such  as  automatic  instantia¬ 
tion  of  generic  mathematical  operators.  We  have  not  yet  programmed  a  unification  algorithm  as  a  VeriML 
procedure;  doing  so  in  the  future  will  allow  us  to  replicate  this  technique  in  the  context  of  VeriML. 

A  calculus  of  tactics.  An  alternative  tactic  development  methodology  is  described  by  Jojgov  and  Geu- 
vers  [2004],  where  a  calculus  of  basic  building  blocks  for  writing  tactics  is  presented.  The  calculus  is  based 
around  an  extension  of  dHOL  with  metavariables  presented  in  Geuvers  and  Jojgov  [2002],  similar  to  our 
own  extensions  of  dHOL.  Though  the  provided  building  blocks  do  not  allow  the  same  generality  as  the 
full  ML  programming  model  we  support,  they  include  an  explicit  unification  construct  between  terms 
that  both  contain  metavariables.  This  is  a  more  general  construct  than  the  pattern  matching  supported  in 
VeriML,  where  only  the  patterns  can  contain  metavariables  and  the  scrutinees  must  be  closed.  Extending 
our  language  so  that  such  a  unification  construct  can  be  built-in  or  programmed  within  the  language  is  a 
high  priority  for  future  development  of  VeriML. 

Automation  tactics  with  user-defined  hints.  A  last  way  that  user-defined  automation  is  added  in  cur¬ 
rent  proof  assistants  is  to  use  automated  tactics  that  implement  a  fixed  proof  search  strategy,  but  can  be 
informed  through  user-defined  hints.  Though  this  is  not  a  tactic  development  technique  per  se,  it  is  rel¬ 
evant  here  since  adding  user-defined  automation  is  one  of  the  main  reasons  why  tactic  development  is 
important.  There  are  multiple  instances  of  this  technique  in  a  wide  variety  of  current  proof  assistants. 

First,  the  Isabelle  simplifier  [Paulson,  1994,  Nipkow  et  ah,  2002]  is  one  such  case:  the  simplifier  is 
a  powerful  rewriting-based  prover  that  is  used  in  most  tactics  and  can  be  informed  through  user-defined 
rewriting  lemmas.  Users  can  register  first-order  lemmas  they  prove  directly  with  the  simplifier,  increasing 
the  available  automation.  This  mechanism  is  quite  similar  in  function  to  our  extensible  equality  checking 
support,  though  it  applies  more  widely  -  owing  both  to  properties  of  the  logic  (propositional  equality 
coincides  with  propositional  equivalence)  and  to  more  sophisticated  infrastructure  for  the  simplifier  (e.g. 
rewriting  lemmas  can  include  premises).  Still,  our  equality  checking  allows  more  sophisticated  extensions 
that  are  not  possible  for  the  Isabelle  simplifier:  we  can  extend  it  not  only  with  first-order  lemmas,  but  with 
arbitrary  decision  procedures  as  well,  written  in  a  general-purpose  programming  model.  For  example,  the 
congruence  closure  function  for  equality  hypotheses  we  support  cannot  be  directly  added  to  the  simplifier. 

Another  instance  of  this  technique  that  is  often  used  as  part  of  large  proof  developments  is  to  use 
a  powerful  user-defined  automation  tactic  that  is  informed  of  domain-specific  knowledge  through  user- 
provided  hints  [e.g.  Chlipala,  2008,  2011,  Morrisett  et  ah,  2012],  The  hints  can  be  as  simple  as  a  rewriting 
lemma  and  as  complicated  as  an  LTac  tactic  that  is  to  be  applied  for  specific  propositions.  We  refer  to  this 
technique  as  adaptive  proof  scripts.  By  replacing  proof  scripts  with  a  single  call  to  the  automation  tactic, 
our  proofs  can  adapt  to  changes  and  additions  in  our  definitions:  if  the  changes  are  small,  automation  will 
still  be  able  to  find  a  proof  and  the  proof  scripts  will  go  through;  larger  changes  will  make  automation 
fail,  but  users  can  respond  to  the  points  of  failure  by  adding  appropriate  lemmas  and  tactics  as  hints.  This 
approach  has  inspired  the  way  that  we  program  and  use  equality  checking  to  provide  automation  to  other 
tactics.  The  extensions  that  we  add  to  the  equality  checking  procedure  can  be  seen  as  a  form  of  adding 
sophisticated  user  hints. 

A  last  instance  of  this  technique  is  the  standard  way  of  developing  proofs  in  fully  automated  provers 
such  as  ACL2  [Kaufmann  and  Strother  Moore,  1996]  and  SMT  solvers  [e.g.  De  Moura  and  Bjorner,  2008] . 
Lemmas  that  have  already  been  proved  play  implicitly  the  role  of  hints.  By  offering  very  sophisticated 
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and  efficient  proof  search  algorithms,  such  provers  can  handle  large  theorems  automatically,  with  a  small 
number  of  additional  auxiliary  lemmas.  Still,  these  provers  offer  poor  or  no  support  for  extensibility  with 
user-defined  tactics;  this  limits  their  applicability  in  cases  where  the  fixed  proof  search  algorithms  available 
are  not  well-suited  to  the  user  domain. 

In  all  such  cases,  the  basic  automation  tactic  can  be  viewed  as  a  small-scale  automation  mechanism,  as 
it  is  used  ubiquitously  and  transparently  throughout  the  proof.  It  is  also  extensible,  owing  to  the  support 
for  user-defined  hints.  This  extensibility  is  key  to  the  success  of  such  techniques,  allowing  users  to  omit 
a  large  amount  of  details;  it  has  directly  inspired  our  focus  on  offering  extensible  small-scale  automation 
mechanisms.  VeriML  is  a  good  candidate  as  the  implementation  language  of  such  automation  tactics, 
especially  compared  to  LTac  or  proof  by  reflection:  other  than  the  benefits  we  have  discussed  already, 
it  allows  the  use  of  hash  tables  and  other  efficient  data  structures  in  order  to  represent  the  database  of 
user-supplied  hints. 

Overall,  VeriML  offers  a  single  language  that  combines  many  of  the  benefits  of  these  existing  approaches. 
Developing  tactics  in  VeriML  is  the  only  methodology  among  the  ones  presented  above  that  combines 
three  characteristics: 

1.  expressivity ,  where  a  full,  side-effectful  programming  model  is  available  for  writing  sophisticated 
tactics; 

2.  convenience ,  where  first-class  constructs  for  pattern  matching  on  arbitrary  open  logical  terms  and 
proof  states  are  available;  and 

3.  safety ,  where  the  behavior  of  tactics  can  be  specified  and  checked  through  a  type  system,  enabling 
increased  static  guarantees  as  well  as  better  maintainability  and  composability. 

Also,  we  have  shown  how  many  of  the  techniques  mentioned  above  can  be  programmed  directly  within 
VeriML.  Last,  it  is  important  to  stress  the  fact  that  users  only  have  to  master  a  single  language  and  a  single 
programming  model.  In  many  current  developments,  the  above  techniques  are  combined  in  order  to  get 
the  automation  behavior  required  as  well  as  good  efficiency.  The  fact  that  VeriML  is  compiled  and  does 
not  need  to  produce  proof  objects  shows  that  similar  efficiency  can  be  achieved  in  the  future  using  a  single 
language. 

10.2  Proof  assistant  architecture 

The  LCF  family  of  proof  assistants  has  had  a  profound  influence  on  the  design  of  VeriML.  The  main 
shared  characteristic  with  VeriML  is  that  these  proof  assistants  follow  the  language-based  approach:  all 
aspects  of  the  proof  assistant,  including  the  basic  tactics,  decision  procedures  and  equality  checking  func¬ 
tions,  as  well  as  user-developed  proofs  and  proof-producing  functions,  are  implemented  within  the  same 
language,  namely  ML.  In  the  LCF  family,  the  core  logic  implementation  is  offered  as  an  ML  module  that 
introduces  two  abstract  data  types:  a  type  of  logical  terms  such  as  propositions  and  domain  objects  (the 
holterm  type  as  mentioned  above)  and  a  type  of  proofs  (holproof).  The  only  way  to  produce  values  of 
such  types  is  through  the  constructor  functions  offered  by  this  module.  These  constructors  are  in  one-to- 
one  correspondence  with  the  logical  rules,  guaranteeing  that  all  values  of  the  proof  type  correspond  to  a 
particular  derivation  in  the  logic.  Also,  basic  destructor  functions  for  looking  into  the  structure  of  logical 
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terms  are  offered.  This  design  leads  to  an  extensible  proof  assistant  that  is  conceptually  clear  and  easy  to 
master.  It  allows  the  use  of  the  full  ML  programming  model  when  writing  proof-producing  functions. 
Thanks  to  the  LCF  design  and  to  the  type  safety  property  of  ML,  full  proof  objects  do  not  need  to  be  pro¬ 
duced  to  guarantee  validity.  The  same  property  is  true  in  VeriML,  as  shown  in  the  proof  erasure  corollary 
of  type  safety.  VeriML  can  be  viewed  as  following  precisely  the  same  architecture,  albeit  with  a  significant 
departure:  the  basic  constructor  and  destructor  functions  are  dependently-typed  instead  of  simply-typed, 
capturing  the  context  and  typing  information  from  the  logic  type  system.  The  correspondence  is  direct 
if  we  consider  the  pattern  matching  support  as  a  principled  way  to  offer  typed  destructors  over  logical 
terms. 

More  recently,  proof  assistants  based  on  a  two-layer  architecture  such  as  Isabelle  and  Coq  have  be¬ 
come  popular.  In  these,  a  higher-level  language  is  made  available  to  users  for  developing  proofs,  different 
from  the  implementation  language  of  the  proof  assistant.  This  allows  increased  interactivity  support, 
convenient  syntax  for  writing  proofs  and  in  the  case  of  Coq/LTac,  a  higher-level  language  for  tactic  de¬ 
velopment.  Despite  the  benefits  that  this  architecture  offers,  it  has  a  significant  downside:  user-defined 
tactic  development  is  de-emphasized  and  the  programming  model  available  for  user-defined  tactics  is  sig¬ 
nificantly  limited  compared  to  ML.  The  Coq  architecture  departs  from  LCF  in  another  significant  way: 
the  LCF  approach  to  hiding  the  data  types  of  the  logic  is  not  followed,  and  tactics  need  to  construct  full 
proof  objects  to  be  checked  by  a  proof  checker.  This  leads  to  significant  scalability  issues  in  large  devel¬ 
opments,  which  are  usually  mitigated  through  increased  use  of  proof-by-reflection.  The  VeriML  design 
allows  increased  interactivity  through  queries  to  the  type  checking  engine;  supports  convenient  tactic  syn¬ 
tax  through  syntactic  sugar  extensions  as  presented  in  Chapter  9;  maintains  the  language-centric  approach 
of  the  original  LCF  design;  and  allows  users  to  control  the  size  of  proof  objects  through  selective  use  of 
the  proof  erasure  semantics. 

The  ACL2  theorem  prover  [Kaufmann  and  Strother  Moore,  1996]  is  an  interactive  proof  assistant 
that  follows  a  very  different  style  than  the  LCF-based  or  LCF-derived  proof  assistants  we  have  presented 
so  far.  It  is  based  on  a  simple  first-order  logic  and  eschews  the  use  of  tactics,  opting  instead  to  use  a 
powerful  automated  theorem  prover  based  on  rewriting  that  takes  into  account  user-defined  rewriting 
lemmas.  The  increased  automation  is  in  large  made  possible  by  the  simplicity  of  the  logic  language  and  the 
use  of  domain-specific  decision  procedures.  ACL2  has  successfully  been  used  for  large-scale  verification 
of  software  [e.g.  Bevier  et  ah,  1987,  Young,  1989]  and  hardware  [e.g.  Brock  et  ah,  1996],  which  shows 
that  rewriting-based  proving  can  be  expressive  and  powerful.  We  would  like  to  investigate  the  addition 
of  ACL2-like  proving  in  our  extensible  rewriting  infrastructure  in  the  future.  Extensions  to  the  existing 
rewriters  in  ACL2  are  made  in  the  form  of  metafunctions;  yet  the  untyped  nature  of  ACL2  does  not  allow 
metafunctions  to  use  facts  that  can  be  discovered  through  the  existing  rewriters  [Hunt  et  ah,  2005],  The 
VeriML  type  system  addresses  this  shortcoming. 

In  the  traditional  ACL2  system  the  proofs  are  not  foundational  and  one  needs  to  trust  the  entirety  of 
the  system  in  order  to  trust  their  validity.  Milawa  [Davis,  2010]  is  a  theorem  prover  that  addresses  this 
shortcoming  of  ACL2.  It  is  based  on  a  similar  first-order  logic  which  includes  a  notion  of  proof  objects. 
A  checker  for  this  logic  constitutes  the  first  level  of  the  Milawa  system.  More  sophisticated  checkers  are 
then  developed  and  proved  sound  within  the  same  logic  using  a  technique  similar  to  proof-by-reflection 
as  presented  above.  In  this  way,  a  large  number  of  the  original  ACL2  features  and  decision  procedures 
are  built  in  successive  layers  and  verified  through  the  checker  of  the  previous  layer,  yielding  a  powerful 
certified  theorem  prover.  The  layered  implementation  of  the  conversion  rule  to  yield  extensible  proof 
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checking  in  VeriML  shares  a  similar  idea;  we  apply  it  to  a  particular  fragment  of  the  logic  (equality  proofs) 
and  not  to  the  full  logic  checker  instead,  but  also  we  use  a  more  expressive  logic  and  a  richer  programming 
language.  Milawa  has  also  been  connected  to  a  verified  implementation  of  its  runtime  system  [Myreen 
and  Davis,  2011],  yielding  perhaps  the  most  high-assurance  proof  assistant  in  existence,  as  it  has  been 
certified  all  the  way  down  to  the  machine  code  that  executes  it.  We  leave  the  investigation  of  similar  ideas 
for  the  VeriML  runtime  to  future  work. 

10.3  Extensibility  of  the  conversion  rule 

CoqMT  [Strub,  2010]  is  an  extension  of  Coq  that  adds  decision  procedures  for  first-order  theories  such  as 
congruence  closure  and  arithmetic  to  the  conversion  rule.  This  increases  the  available  small-scale  automa¬ 
tion  support,  reducing  the  required  manual  proof  effort  in  many  cases;  also,  it  makes  more  dependently 
typed  terms  typeable.  Still  the  metatheory  of  CIC  needs  significant  new  additions  in  order  to  account  for 
the  extended  conversion  rule  [Blanqui  et  ah,  2007],  Also,  the  added  decision  procedures  are  not  verified, 
increasing  the  trusted  base  of  the  system. 

NuPRL  [Constable  et  ah,  1986,  Allen  et  ah,  2000]  supports  an  extensional  type  theory  instead  of  an 
intensional  as  in  the  case  of  Coq.  This  translates  to  a  very  powerful  conversion  rule,  where  all  provably 
equal  terms  are  made  definitionally  equal.  The  extensional  conversion  rule  destroys  decidability  for  proof 
checking,  but  allows  a  large  number  of  decision  procedures  to  be  integrated  within  the  conversion  rule, 
resulting  in  good  small-scale  automation  support.  Still,  these  decision  procedures  become  part  of  the 
trusted  base  of  the  system. 

The  approach  to  the  conversion  rule  we  have  described  in  this  dissertation  amounts  to  replacing  the 
conversion  rule  with  explicit  proof  witnesses  and  re-implementing  the  computational  aspect  of  the  con¬ 
version  rule  outside  the  logic,  as  a  VeriML  function.  This  allows  us  to  extend  conversion  with  arbitrary 
user-defined  decision  procedures,  without  metatheoretic  additions  to  the  logic  and  without  increasing  the 
trusted  base.  It  also  allows  the  implementation  of  different  evaluation  strategies  for  the  existing  conver¬ 
sion  rule.  We  have  also  implemented  the  decision  procedures  used  in  CoqMT,  arriving  at  a  conversion 
rule  of  similar  expressivity.  We  believe  that  our  ideas  can  be  extended  to  a  full  type-theoretic  logic  instead 
of  the  simple  higher-order  logic  we  support,  but  have  left  this  as  future  work. 

Geuvers  and  Wiedijk  [2004]  argue  about  why  replacing  the  conversion  rule  with  explicit  witnesses  is 
desirable  for  foundational  proof  objects.  The  logic  they  present  is  in  fact  very  similar  to  dHOL£.  They 
leave  the  question  of  how  to  reconcile  the  space  savings  of  the  implicit  conversion  approach  with  the 
increased  trust  of  their  explicit  witnesses  approach  as  future  work;  we  believe  our  approach  addresses  this 
question  successfully. 

Gregoire  [2003]  presents  a  different  sort  of  extension  to  the  conversion  rule:  an  alternative  evaluation 
strategy  for  the  /^-conversion  rule  in  Coq,  based  on  compilation  of  CIC  terms  into  an  abstract  machine. 
This  evaluation  strategy  significantly  speeds  up  conversion  in  many  situations  and  is  especially  useful 
when  evaluating  decision  procedures  implemented  through  proof-by-reflection.  Still,  this  implementation 
of  the  conversion  rule  represents  a  significant  increase  in  the  trusted  base  of  the  system;  this  is  possibly  the 
reason  why  the  independent  Coq  proof  checker  coqchk  does  not  use  this  implementation  of  conversion 
by  default.  Though  in  our  examples  we  have  implemented  a  very  simple  call-by-name  interpretation-based 
evaluation  strategy  for  (/5 '-conversion,  our  approach  to  conversion  allows  for  much  more  sophisticated 
implementations,  without  requiring  any  increase  in  the  overall  trusted  base. 
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10.4  Type-safe  manipulation  of  languages  with  binding 

The  Beluga  programming  language  [Pientka,  2008,  Pientka  and  Dunfield,  2008]  is  perhaps  the  most 
closely  related  language  to  VeriML.  It  is  a  language  designed  for  type-safe  manipulation  of  LF  terms  with 
a  similar  two-layer  architecture:  LF  comprises  the  logical  level  (corresponding  to  dHOL  in  our  system), 
and  Beluga  the  computational  level  (corresponding  to  VeriML).  LF  itself  is  a  logical  framework  that  can 
be  used  to  represent  the  terms  and  derivations  of  various  logics,  including  the  dHOL  logic  we  describe 
[Harper  et  ah,  1993],  Beluga  uses  contextual  terms  to  represent  open  LF  terms  and  their  types;  it  provides 
dependently  typed  constructs  to  manipulate  such  terms,  including  a  dependently-typed  pattern  matching 
construct  for  contexts  and  contextual  terms.  The  ML -style  universe  supported  is  limited  compared  to 
VeriML,  as  it  does  not  include  mutable  references.  The  use  of  contextual  type  theory  [Nanevski  et  ah, 
2008b]  in  Beluga  has  been  of  crucial  importance  in  the  design  of  VeriML.  Through  VeriML,  we  show  how 
a  language  based  on  similar  ideas  can  be  used  to  write  small-scale  and  large-scale  automation  procedures 
and  can  serve  as  an  alternative  architecture  for  proof  assistants. 

Perhaps  the  biggest  difference  between  the  two  languages  is  that  Beluga  aims  to  be  useful  as  a  meta¬ 
logic  of  the  LF  system  with  Beluga  functions  representing  meta-proofs  about  LF-encoded  logics.  We  have 
chosen  to  focus  on  proofs  in  the  well-established  HOL  logic  instead.  Therefore  VeriML  functions  are 
not  seen  as  meta-proofs,  but  merely  as  functions  that  produce  foundational  proofs.  This  allows  us  to  add 
features  such  as  mutability  and  non-covering  pattern  matching  whose  presence  in  a  meta-logic  would  be 
problematic  due  to  soundness  issues.  Also,  our  metatheoretic  proofs  about  /HOL  and  VeriML  present 
improvements  over  the  related  Beluga  proofs,  such  as  the  use  of  hybrid  deBruijn  variables  to  elucidate 
the  various  substitution  operations  we  define,  and  our  novel  handling  of  pattern  matching.  A  recent 
extension  to  Beluga  [Cave  and  Pientka,  2012]  employs  a  metatheoretic  study  with  similar  orthogonality 
characteristics  between  the  logic  and  the  computational  language  as  does  our  own  development.  This 
extension  also  supports  recursive  types  and  type  constraints.  The  former  are  already  part  of  the  ML 
universe  we  support;  the  latter  are  similar  to  the  equality  constraints  we  use  for  /HOL.  terms  but  are  also 
applicable  in  the  case  of  contexts.  Still,  the  constraints  are  solved  using  a  fixed  procedure  that  is  built  into 
the  Beluga  type  checker.  We  have  shown  how  to  solve  such  constraints  through  user-defined  procedures, 
using  a  combination  of  staging  and  the  collapsing  transformation. 

Delphin  [Poswolsky  and  Schtirmann,  2008,  Poswolsky,  2009]  is  a  similar  language  to  Beluga,  used 
for  type-safe  manipulation  of  LF  terms.  The  main  difference  is  that  manipulation  of  open  terms  does 
not  make  use  of  contextual  types  but  makes  use  of  an  ambient  context  instead.  This  leads  to  simpler 
code  compared  to  Beluga  in  the  most  common  case,  as  contexts  do  not  have  to  be  mentioned.  Still 
this  solution  to  open  terms  is  not  as  general  as  contextual  types,  as  we  cannot  maintain  terms  that  inhabit 
entirely  different  contexts.  We  show  how  the  ambient  context  can  be  supported  through  extensions  at  the 
syntactic  level,  offering  the  same  benefits  as  Delphin  while  maintaining  the  generality  of  the  contextual 
types  approach.  Also,  our  use  of  contextual  types  allows  us  to  use  the  normal  typing  rules  for  mutable 
references;  the  use  of  ambient  contexts  would  require  seemingly  ad-hoc  restrictions  as  side  conditions  in 
order  to  maintain  type  safety. 

A  number  of  languages  support  embedding  open  terms  of  a  typed  object  language  within  a  meta¬ 
language  in  a  type-safe  way;  some  examples  are  MetaML  [Taha  and  Sheard,  2000],  FreshML  [Shinwell 
et  ah,  2003],  and  MetaHaskell  [Mainland,  2012],  With  the  exception  of  FreshML,  these  languages  do 
not  allow  pattern  matching  on  such  embedded  open  terms.  MetaML  is  especially  interesting  as  its  pri¬ 
mary  motivation  is  to  support  staging,  leading  the  object  and  meta  language  to  coincide.  While  VeriML 
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supports  staging,  it  only  does  so  for  closed  expressions  and  thus  does  not  require  special  treatment  for 
quoted  VeriML  expressions.  MetaML  uses  environment  classifiers  in  order  to  differentiate  between  open 
terms  inhabiting  different  contexts  at  the  typing  level;  this  enables  hygienic  treatment  of  bound  variables 
-  that  is,  bound  variables  cannot  escape  the  scope  of  their  binder.  The  solution  based  on  classifiers  can 
be  viewed  as  a  restriction  of  the  contextual  approach  we  follow,  where  all  open  terms  must  inhabit  fully 
polymorphic  contexts.  FreshML  and  MetaHaskell  do  not  support  hygienic  treatment  of  variables;  this 
would  destroy  type-safety  in  our  setting.  This  can  be  remedied  in  the  case  of  FreshML  through  the  use 
of  static  obligations  that  resemble  a  logic  [Pottier,  2007];  we  believe  that  the  contextual  type  theory  so¬ 
lution  is  much  simpler.  The  solution  used  in  MetaHaskell  also  employs  polymorphic  contexts.  Overall, 
the  contextual  type  theory-based  solution  of  VeriML  offers  a  number  of  advantages:  type-safe  and  hy¬ 
gienic  embedding  of  open  terms,  even  when  the  object  language  is  dependently-typed;  variable  contexts 
that  combine  a  polymorphic  part  with  concrete  variables;  and  type-safe  manipulation  of  the  embedded 
terms  as  well.  We  believe  that  the  metatheoretic  treatment  we  have  presented  presents  a  recipe  for  com¬ 
bining  a  typed  object  language  with  a  typed  meta  language,  yielding  these  benefits.  As  future  work,  we 
would  like  to  apply  this  recipe  to  languages  with  full  (heterogeneous)  staging  support  such  as  MetaML 
and  MetaHaskell. 

10.5  Mixing  logic  with  computation 

The  YNot  framework  [Nanevski  et  ah,  2008a]  is  similar  to  VeriML  as  it  mixes  a  logical  language  - 
specifically  CIC  -  with  side-effectful  computation,  such  as  the  use  of  mutable  references.  Yet  the  approach 
taken  is  profoundly  different,  as  side-effectful  computations  become  integrated  within  the  existing  logical 
language  through  a  monadic  type  system.  Combined  with  proof-by-reflection,  this  approach  could  lead 
to  type-safe  decision  procedures  that  make  use  of  side  effects,  yet  we  are  not  aware  of  any  such  usage  of 
the  YNot  framework.  Also,  this  approach  requires  a  significant  addition  both  to  the  metatheory  of  the 
logic  language  as  well  as  its  implementation. 

The  Trellys  project  [Casinghino  et  ah,  2011]  presents  another  potential  combination  between  a  logic 
and  a  side-effectful  computational  language.  The  logic  is  a  sub-language  of  the  computational  language, 
where  non-termination  and  other  side-effects  are  not  allowed.  Still,  logical  terms  can  reason  about  com¬ 
putational  terms,  even  side-effectful  ones.  Compared  to  VeriML,  this  approach  successfully  addresses 
the  duplication  of  data  structures  and  functions  between  the  two  levels  (consider,  for  example,  the  two 
definitions  of  lists  in  Chapter  9),  as  well  as  the  inability  to  reason  about  functions  in  the  computational 
language.  Still,  the  resulting  logic  is  non-standard.  The  apparent  duplication  of  definitions  in  VeriML  can 
be  addressed  in  the  future  by  a  process  similar  to  type  promotion  in  Haskell  [Yorgey  et  ah,  2012]:  the 
same  surface-level  definition  results  in  definitions  at  both  the  logical  and  the  computational  level. 
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Chapter  11 

Conclusion  and  future  work 


The  work  presented  in  this  dissertation  started  from  a  simple  observation:  the  language  support  for  writ¬ 
ing  new  automation  procedures  in  current  proof  assistants  is  lacking.  This  leads  to  automation  that  is 
error-prone,  difficult  to  maintain  and  extend;  or  requires  mastery  of  the  proof  assistant  to  a  level  that 
only  advanced  users  possess.  Seeing  how  important  it  is  to  automate  trivial  and  non-trivial  details  in  large 
proofs,  this  is  a  shortcoming  of  profound  importance.  It  ultimately  leads  to  a  proof  development  pro¬ 
cess  that  requires  significant  manual  effort,  even  when  the  actual  proof  at  hand  is  well-understood  or  not 
particularly  deep  in  a  mathematical  sense  -  as  is  often  the  case  in  software  certification  tasks. 

A  second  key  observation  is  that  the  boundary  between  trivial  and  non-trivial  details  is  thin  and  not 
constant.  The  non-trivial  details  of  a  particular  domain  become  trivial  details  as  soon  as  we  move  into  a 
more  complicated  domain.  Therefore  the  same  automation  procedures  should  be  used  in  either  case,  with 
minimal  user  effort.  Also,  when  using  automation  to  handle  trivial  details  in  a  way  that  is  transparent  to 
the  user,  these  details  should  not  necessarily  be  expanded  out  to  their  full  formal  counterpart.  The  reason 
is  that  trivial  details  occur  pervasively  throughout  proofs,  and  full  expansion  leads  to  prohibitively  large 
formal  proofs  that  take  a  long  time  to  check.  This  suggests  that  the  automation  procedures  themselves 
should  be  verified  upon  definition,  instead  of  verifying  their  results  upon  evaluation.  In  this  way,  we  can 
be  certain  that  automation  does  not  make  false  claims,  even  when  formal  proofs  are  not  produced. 

These  two  observations  combined  result  in  the  basic  design  idea  behind  VeriML:  a  programming  lan¬ 
guage  that  enables  the  development  of  verified  automation  procedures,  using  an  expressive  programming 
model  and  convenient  constructs  tailored  to  this  task.  We  achieve  expressiveness  by  including  the  side- 
effectful,  general-purpose  programming  model  of  ML  as  part  of  the  language;  convenience  by  adding 
first-class  support  for  introducing  proofs,  propositions  and  other  logical  terms  as  well  as  pattern  matching 
over  them  -  the  exact  constructs  that  form  the  main  building  blocks  of  automation  procedures.  The  verifi¬ 
cation  of  automation  procedures  is  done  in  a  light-weight  manner,  so  that  it  does  not  become  a  bottleneck 
in  itself.  It  is  the  direct  product  of  two  mechanisms.  The  first  is  a  rich  type  system  that  keeps  information 
about  the  logical  terms  that  are  manipulated  and  enables  user  to  assign  detailed  signatures  to  their  automa¬ 
tion  procedures.  The  second  is  a  staging  mechanism  which  is  informed  by  the  typing  information  and 
allows  the  use  of  existing  automation  in  order  to  minimize  the  proof  burden  associated  with  developing 
new  automation  procedures.  The  use  of  the  type  system  also  leads  to  a  principled  programming  style  for 
automation  procedures,  making  them  more  composable  and  maintainable. 

In  summary,  VeriML  is  therefore  a  “programming  language  combining  typed  manipulation  of  logical 
terms  with  a  general-purpose  side-effectful  programming  model”,  as  is  stated  in  my  thesis.  In  this  dis- 
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sertation,  I  have  described  the  overall  design  of  the  language;  I  have  shown  that  the  language  is  type-safe 
and  that  automation  procedures  do  not  need  to  produce  full  proofs,  through  an  extensive  metatheoretic 
study;  I  presented  an  implementation  of  the  language,  including  a  type  inferencing  engine  and  a  compiler 
for  it;  and  I  described  a  number  of  examples  written  in  the  language,  which  have  been  previously  hard  to 
implement  using  the  existing  approaches.  Also,  I  have  shown  that  various  features  of  the  architecture  of 
modern  proof  assistants  can  be  directly  recovered  and  generalized  through  the  VeriML  design,  rendering 
the  VeriML  language  as  a  proof  assistant  in  itself.  Proofs,  as  well  as  automation  procedures  and  other 
tactics  can  be  written  as  VeriML  programs.  Interactive  support  for  writing  proofs  is  recovered  as  queries 
to  the  VeriML  type  checker;  it  is  generalized  to  the  case  of  tactics  as  well,  allowing  them  to  be  developed 
interactively  as  well.  Also,  the  conversion  rule  that  is  part  of  the  trusted  core  of  modern  proof  assistants, 
can  be  programmed  instead  in  VeriML,  thus  allowing  sophisticated  user  extensions  while  maintaining 
logical  soundness. 

The  VeriML  design  therefore  constitutes  a  viable  alternative  to  the  architecture  of  proof  assistants, 
one  that  represents  a  return  to  form:  a  single  meta-language  is  used  to  implement  all  aspects  of  the  proof 
assistant,  allowing  maximum  extensibility.  This  was  the  rationale  behind  the  original  LCF  system  and 
the  original  design  of  ML  [Milner,  1972],  Our  work  essentially  updates  this  language-centric  design  with 
the  modern  discoveries  in  the  domain  of  dependently  typed  languages,  resulting  in  a  meta-language  that 
can  be  used  for  conducting  proofs  and  for  programming  verified  proof  procedures  with  reduced  manual 
effort. 

Still,  a  long  way  lies  ahead  of  us  until  an  actual  VeriML  implementation  can  be  a  realistic  alternative  to 
existing  proof  assistants.  A  number  of  features  that  are  essential  for  practical  purposes  are  not  yet  covered 
by  our  design  and  its  corresponding  metatheory  and  implementation.  We  will  first  focus  on  features 
where  the  main  challenge  spans  across  the  theory  and  the  implementation;  features  that  are  mostly  related 
to  engineering  issues  of  the  implementation  will  follow. 

Metatheory 

Meta-N-terms.  In  order  to  be  able  to  manipulate  open  logical  terms,  we  closed  them  over  the  variable 
environment  they  depend  on.  This  led  to  the  introduction  of  contextual  terms  or  meta-terms,  along 
with  their  corresponding  notions  of  meta-variables,  contexts  and  substitutions.  The  computational 
language  of  VeriML  allows  us  to  introduce  contextual  terms,  bind  them  to  meta-variables  and  pat¬ 
tern  match  to  look  into  their  structure.  In  many  situations,  it  would  be  useful  to  be  able  to  close  the 
contextual  terms  once  more,  over  the  meta-variables  they  depend  on.  These  would  then  be  charac¬ 
terized  as  meta-2-terms,  as  they  would  contain  not  only  normal  logical  variables  but  meta-variables 
as  well.  By  repeating  this  process  we  would  be  able  to  manipulate  such  meta-2-terms  directly  inside 
VeriML  using  similar  constructs  such  as  the  pattern  matching  we  already  support. 

In  this  dissertation  we  have  already  presented  a  situation  where  this  would  be  useful,  namely  the 
static  evaluation  of  proof  expressions  within  tactics  -  as  exemplified  by  the  StaticEqual  expres¬ 
sion  we  often  use  throughout  our  examples.  Such  proof  expressions  contain  meta-terms,  usually 
instantiated  through  type  inference;  these  meta-terms  contain  meta-variables,  standing  for  the  input 
arguments  of  the  tactic  we  are  defining.  In  order  to  evaluate  these  proof  expressions,  we  would  there¬ 
fore  need  to  perform  pattern  matching  where  the  scrutinee  is  an  open  meta-term.  Yet  our  pattern 
matching  theorem  and  algorithm  only  covers  the  case  where  the  scrutinee  is  closed  and  the  pattern 
is  open.  This  is  for  good  reason  too,  as  generalizing  to  the  case  where  both  the  scrutinee  and  the 
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pattern  contain  meta-variables,  together  with  the  fact  that  the  scrutinee  might  contain  non-identity 
substitutions,  changes  the  operation  from  pattern  matching  to  unification  which  would  destroy 
the  decidability  and  determinism  properties  of  the  operation.  The  way  we  have  addressed  this  is 
the  use  of  the  collapsing  transformation,  which  turns  the  open  meta-terms  into  equivalent  closed 
ones  which  pattern  matching  can  already  handle.  Yet  this  transformation  is  only  applicable  under 
certain  limitations.  If  we  had  support  for  manipulating  meta-2-terms  instead,  this  transformation 
would  not  be  necessary  and  we  would  be  able  to  lift  such  limitations. 

Another  situation  where  meta-2-terms  show  up  is  the  notion  of  proof  state,  that  is,  the  type  of 
an  incomplete  proof.  We  can  view  the  current  context  and  the  current  goal,  as  captured  through 
type  inference,  as  the  notion  of  proof  state  that  VeriML  supports.  This  is  limited  compared  to 
current  proof  assistants:  most  proof  assistants  allow  multiple  hypotheses-goals  pairs  to  be  part  of 
the  current  proof  state,  as  well  as  unification  variables  -  variables  to  be  implicitly  instantiated  based 
on  their  usage.  Such  variables  are  often  useful  when  solving  goals  involving  existentials,  or  when 
using  universally  quantified  lemmas:  we  can  delay  the  instantiation  of  the  existential  witness,  or  of 
the  arguments  of  the  lemmas,  until  their  identity  is  trivial  to  deduce  from  the  context.  We  could 
encode  such  notions  of  proof  state  as  meta-2-terms,  and  we  would  therefore  need  pattern  matching 
over  meta-2-terms  as  well  as  their  associated  meta-2-contexts  in  order  to  work  with  such  proof  states 
and  incomplete  proofs. 

A  last  situation  where  meta-2-terms  and  potentially  even  higher-order  meta-N-terms  would  be  use¬ 
ful  is  in  programming  a  well-typed  unification  procedure  in  VeriML:  namely,  a  procedure  that  takes 
two  open  terms  with  meta-variables  (representing  unification  variables),  and  decides  whether  a  sub¬ 
stitution  exists  that  makes  the  two  terms  match.  As  mentioned  earlier,  the  problem  of  unification  of 
dHOL  terms  is  undecidable,  as  it  is  equivalent  to  higher-order  unification  in  the  d-calculus.  Yet  un¬ 
decidability  can  be  overcome  by  enabling  programmatic  control.  We  would  therefore  like  to  follow 
a  similar  approach  as  we  did  for  the  equality  proofs  of  the  conversion  rule  to  handle  unification:  by 
programming  unification  inside  VeriML  instead  of  making  it  a  fixed  procedure,  we  would  be  able 
to  develop  further  extensions  to  it,  to  handle  more  cases.  We  believe  that  being  able  to  manipulate 
meta-N-terms  plus  their  accompanying  notions  of  contexts  and  substitutions,  would  allow  us  to 
program  this  procedure  inside  VeriML.  Such  an  extensible  unification  procedure  would  allow  us 
to  treat  the  remaining  small-scale  automation  mechanisms  in  current  proof  assistants,  which  are  all 
unification-based,  in  a  similar  manner  to  the  conversion  rule,  with  similar  benefits. 

Extending  our  metatheory  to  meta-2-terms,  as  well  as  higher  meta-N-terms,  should  be  possible  by 
repeating  the  process  we  described  in  Chapter  4  for  deriving  meta-l-terms  and  the  associated  proofs. 
In  fact,  we  have  done  our  proofs  with  such  an  extension  in  mind,  making  sure  that  the  operations 
and  theorems  of  the  base  level  of  normal  logical  terms  exactly  match  up  with  the  operations  and 
theorems  of  the  meta-l-level  of  contextual  terms.  Therefore  repeating  this  process  once  more,  or 
inductively  up  to  N,  should  in  principle  give  us  the  desired.  Still,  further  extensions  would  be 
needed  for  meta-2-  or  meta-N-terms  to  be  truly  useful,  such  as  being  able  to  write  code  that  is 
polymorphic  over  meta-levels  and  also  to  be  able  to  pattern  match  on  substitutions  in  the  same 
way  that  we  pattern  match  on  terms  and  contexts.  Managing  this  complexity  in  order  to  arrive  at 
a  conceptually  clear  description  of  the  metatheory  and  the  language  would  be  a  process  in  itself;  it 
would  be  an  even  more  significant  challenge  to  find  ways  to  mask  this  complexity  at  the  level  of  the 
end  user  of  the  language. 
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Inductive  definitions.  VeriML  needs  better  support  for  inductive  types  and  inductive  predicates.  For 
the  time  being,  inductive  definitions  are  opaque  -  there  is  no  pattern  matching  support  for  them, 
which  precludes  writing  VeriML  functions  that  operate  directly  on  such  definitions.  We  have  so  far 
addressed  this  shortcoming  through  ad-hoc  means,  such  as  the  meta-generation  of  rewriters  for  the 
elimination  principles.  We  should  be  able  to  write  such  code  in  a  generic  manner  within  VeriML 
supporting  all  inductive  definitions,  while  retaining  the  increased  typing  information  that  VeriML 
offers.  This  would  allow  the  definition  of  typed  generic  induction  and  inversion  tactics,  which  have 
proved  to  be  one  of  the  main  hindrances  of  using  inductive  definitions  in  our  current  developments. 
The  inversion  tactic  is  especially  notorious  even  in  current  proof  assistants,  as  its  behavior  is  hard 
to  describe  formally;  being  able  to  give  it  a  precise  signature  through  typing  would  be  an  interesting 
potential. 

The  main  challenge  in  supporting  inductive  definitions  comes  from  the  fact  that  their  well-formedness 
conditions  are  syntactic  in  nature,  instead  of  being  based  on  the  judgemental  approach.  We  have 
partly  addressed  this  in  the  case  of  the  positivity  condition  and  in  the  handling  of  parameters,  yet 
syntactic  side-conditions  remain.  This  precludes  us  from  applying  the  techniques  we  used  in  our 
metatheory  in  order  to  derive  well-formed  patterns  over  such  definitions,  as  our  techniques  assume 
that  the  typing  of  the  object  language  is  described  as  a  pure  judgement. 

Controlling  representations.  We  use  a  generic  representation  for  logical  terms,  but  we  believe  that  spe¬ 
cialized  representations  for  use  under  specific  circumstances  could  improve  the  efficiency  of  VeriML 
programs  significantly.  For  example,  closed  natural  numbers  up  to  a  certain  number  could  be  repre¬ 
sented  as  machine  integers  and  their  operations  such  as  addition  and  multiplication  could  be  imple¬ 
mented  through  machine  instructions.  A  more  ambitious  use  case  for  the  same  idea  has  to  do  with 
the  equality  checking  function  described  in  Section  9.4.  This  function  needs  to  construct  a  hash 
table  representing  equivalence  classes  anew  for  every  context.  We  could  instead  add  an  additional 
representation  to  contexts  that  keep  track  of  the  hash  table  as  well,  calling  the  right  function  when 
a  new  element  enters  the  current  context.  Furthermore,  the  proof  erasure  procedure  we  describe 
for  proof  objects  could  be  seen  as  choosing  a  unit  representation  for  proof  objects;  the  same  repre¬ 
sentation  could  be  used  in  order  to  erase  other  terms  that  do  not  influence  the  runtime  behavior  of 
programs  and  are  only  useful  during  type  checking.  It  is  interesting  to  see  if  user-defined  represen¬ 
tations  for  existing  classes  of  logical  terms  can  be  maintained  and  manipulated  while  maintaining 
type  safety.  The  main  challenge  would  be  to  coordinate  between  the  set  of  patterns  allowed  over 
terms  and  the  information  that  the  actual  representation  of  such  terms  contains. 

Implementation 

Our  prototype  implementation  has  served  well  as  an  experimentation  platform  for  the  work  presented  in 
this  dissertation.  Still  it  is  far  from  a  language  implementation  ready  for  the  end  user  of  VeriML.  The  ML 
core  of  the  language  does  not  support  many  of  the  conveniences  present  in  modern  functional  languages 
like  OCaml  and  Haskell,  such  as  Hindley-Milner  type  inference,  first-class  modules,  type  classes  and  ef¬ 
fect  encapsulation  through  monads.  The  syntax  and  constructs  of  the  language  are  more  verbose  in  many 
situations,  such  as  pattern  matching  over  normal  datatypes,  and  error  reporting  is  rudimentary.  Last,  our 
compilation  methodology  goes  through  translation  to  OCaml,  which  introduces  the  unnecessary  over¬ 
head  of  re-typechecking  the  resulting  OCaml  AST.  Our  implementation  of  the  kHOL  logic  has  similar 
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shortcomings. 

In  order  to  address  these  issues,  we  would  like  to  work  on  a  new  implementation  of  VeriML  that 
extends  an  existing  programming  language  implementation  with  the  VeriML -specific  constructs  for  an 
existing  logic  implementation,  so  as  to  inherit  the  engineering  effort  that  has  gone  into  them.  The  OCaml 
implementation  together  with  the  CIC  logic  implementation  used  in  Coq  are  natural  choices  for  this 
purpose,  as  they  would  allow  us  to  use  VeriML  as  an  additional  language  in  Coq,  without  enlarging  its 
trusted  base.  In  this  way  we  would  also  be  able  to  reuse  the  large  library  and  proof  developments  that  are 
already  implemented  in  Coq,  and  ease  adoption  of  VeriML  in  situations  where  it  can  be  of  benefit.  One 
challenge  with  this  approach  is  to  extend  the  design  and  metatheory  of  VeriML  so  as  to  incorporate  the 
CIC  logic,  which  contains  many  features  not  in  dHOL.  We  are  confident  that  the  main  techniques  used 
in  our  current  metatheory  are  still  applicable  in  the  case  of  CIC. 

The  VeriML  extension  should  be  as  isolated  as  possible  from  the  main  OCaml  implementation,  re¬ 
flecting  the  orthogonality  between  the  /HOL-related  constructs  and  the  ML  core  that  characterizes  our 
metatheory.  This  would  allow  development  of  further  extensions  to  VeriML  without  requiring  changes 
to  the  core  OCaml  implementation;  it  would  also  minimize  the  cost  associated  with  updating  to  newer 
versions  of  the  OCaml  implementation  as  they  become  available.  We  expect  the  main  challenge  to  be 
inserting  hooks  into  the  main  OCaml  modules,  such  as  the  AST  definitions,  the  type  checker  and  the 
compiler  to  bytecode,  so  that  they  make  calls  to  corresponding  extension  modules.  Such  changes  are  a 
particular  instance  of  the  expression  problem;  we  might  be  able  to  make  use  of  the  existing  solutions  to  it 
[e.g.  Swierstra,  2008], 

One  important  aspect  of  any  implementation  of  VeriML  is  the  capabilities  of  the  type  inferencing 
engine.  Our  current  support  for  type  inference  of  logical  terms,  as  described  in  Chapter  8,  is  based 
around  greedy  mutable  reference-based  unification,  using  invertible  syntactic  operations  on  terms.  This 
approach  is  both  versatile  and  efficient,  yet  we  would  like  to  explore  further  enhancements  to  it  and 
use  the  same  approach  for  computational  expressions  and  types,  and  all  the  other  kinds  of  terms  in  our 
language.  The  main  extension  to  this  approach  would  be  to  allow  some  backtracking  when  more  than 
one  typing  alternatives  are  possible  and  also  a  way  to  interoperate  with  constraint-based  type  inference 
as  described  by  Pottier  and  Remy  [2005],  The  inference  engine  in  recent  versions  of  OCaml  is  based 
on  this  mechanism,  where  type  inference  is  formulated  as  a  stage  of  constraint  generation  followed  by 
a  stage  of  constraint  solving.  This  formulation  is  well-suited  to  our  purposes  of  extending  the  OCaml 
implementation,  as  VeriML-related  constraints  could  be  presented  as  an  additional  kind  of  constraints  to 
be  solved  by  an  independent  constraint  solver  based  around  unification  of  logical  terms. 

Another  issue  we  would  like  to  address  is  the  duplication  of  definitions  of  types  and  functions  be¬ 
tween  the  logic  and  the  computational  language.  In  many  cases  the  same  definition  is  directly  applicable 
both  in  the  logical  and  in  the  computational  level  -  e.g.  definition  of  recursive  types  without  negative 
occurrences  or  mutable  references,  or  of  recursive  functions  that  are  pure  and  total.  We  are  confident  that 
such  cases  can  be  handled  by  offering  surface-level  syntax  that  performs  both  definitions  at  the  logical 
and  at  the  computational  level,  allowing  users  to  treat  each  definition  at  either  level  transparently.  This 
correspondence  is  not  as  direct  in  cases  where  the  boundary  between  the  logical  and  the  computational 
level  is  crossed,  such  as  tactics  that  pattern  match  on  logical  terms  and  data  types  that  use  ML -only  types 
such  as  mutable  references.  Still,  it  is  interesting  to  explore  whether  surface  syntax  can  be  offered  in  such 
situations  as  well  that  hides  some  of  the  complexities  associated  with  having  two  strongly  isolated  levels 
in  the  language. 


245 


Translating  to  reflective  CIC  procedures  would  be  an  alternative  implementation  strategy  for  the  pure 
subset  of  VeriML.  This  option  might  be  worth  exploring  in  parallel  to  the  above  described  strategy.  The 
main  benefit  of  this  approach  would  be  that  we  would  be  able  to  reason  about  VeriML  functions  using  the 
full  expressivity  of  the  CIC  logic,  instead  of  the  comparatively  more  limited  expressivity  of  the  VeriML 
type  system.  The  challenge  of  this  approach  would  be  to  reify  a  large  subset  of  the  CIC  logic  as  an 
inductive  datatype  within  CIC,  as  well  as  the  corresponding  typing  relation.  Even  though  considerable 
effort  has  gone  into  similar  considerations  [e.g.  Chapman,  2009,  Chapman  et  ah,  2010],  this  is  still  largely 
an  open  problem. 

User  interface 

When  viewed  as  a  proof  assistant,  the  user  interface  that  VeriML  offers  becomes  very  important.  Ex¬ 
ploring  ways  that  the  VeriML  design  can  enhance  the  user  experience  becomes  an  interesting  problem  in 
itself.  For  example,  traditional  proof  assistants  usually  have  two  different  languages  for  writing  proofs: 
one  that  follows  the  imperative  style,  where  the  focus  is  placed  on  the  tactics  applied;  and  one  that  follows 
the  declarative  style,  where  the  intermediate  steps  of  the  proof  are  the  main  focus.  We  believe  that  the 
increased  typing  information  present  in  VeriML  would  allow  us  to  mix  these  two  styles,  by  writing  two 
sets  of  strongly-typed  tactics  tailored  to  each  style  and  using  type  inference  to  mediate  the  proof  state 
between  them. 

Supporting  interactive  development  of  VeriML  proofs  and  tactics  presents  an  interesting  user-interface 
design  issue,  especially  in  the  presence  of  our  staging  support.  The  proof  script  languages  used  in  current 
proof  assistants  have  clear  breakpoints,  allowing  partial  proof  scripts  to  be  evaluated  up  to  a  certain  point. 
Interactive  development  environments  such  as  Proof  General  [Aspinall,  2000]  have  a  notion  of  “locked 
region”  that  follows  such  breakpoints,  and  moves  as  subsequent  steps  of  proof  scripts  are  performed. 
Proof  state  information  is  presented  to  the  user,  as  it  is  determined  for  the  currently  active  breakpoint. 
In  VeriML,  proof  expressions  do  not  necessarily  have  a  similar  linear  structure  with  well-defined  break 
points.  Partial  proof  expressions  can  also  have  missing  parts  at  various  points.  The  presence  of  staged 
expressions  complicates  the  evaluation  order  of  expressions  further;  such  expressions  also  need  to  be  able 
to  provide  information  about  their  result  to  the  user,  e.g.  in  order  to  allow  them  to  fix  erroneous  appli¬ 
cations  of  the  conversion  rule.  These  issues  are  even  more  serious  in  the  case  of  tactics,  whose  structure 
is  based  around  pattern  matching  and  is  therefore  certainly  not  linear.  Yet,  proof  state  and  further  typing 
information  is  available  at  all  program  points,  even  for  incomplete  proof  expressions  and  incomplete  tac¬ 
tics,  by  querying  the  type  checking  engine  of  VeriML.  In  order  to  address  the  above  issues  and  make  use 
of  such  information  to  offer  a  better  interface  to  the  user,  we  expect  that  increased  coupling  between  the 
interactive  development  environment  and  the  VeriML  implementation  will  be  essential,  departing  further 
from  the  traditional  REPL-based  interface  to  proof  assistants. 

Other  uses  of  the  VeriML  design 

We  believe  that  VeriML  could  be  used  to  investigate  a  number  of  interesting  possibilities,  other  than  the 
examples  seen  so  far  and  the  traditional  usage  scenario  of  proof  assistants.  First,  we  believe  that  VeriML 
could  be  used  to  realize  projects  such  as  the  extensible  low-level  programming  language  and  software  cer¬ 
tification  framework  Bedrock  [Chlipala,  2011],  The  additional  expressivity,  extensibility  and  efficiency 
that  a  realistic  VeriML  implementation  would  be  able  to  offer  to  tactic  programming  would  address  the 
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main  issues  of  this  framework.  Also,  we  believe  that  the  first-class  support  for  proofs  in  VeriML  could 
render  it  an  appealing  platform  for  implementing  a  number  of  certifying  tools,  such  as  compilers,  static 
analysis  tools  and  SMT  solvers.  The  combination  of  such  tools  with  a  software  certification  framework 
such  as  Bedrock  could  result  in  an  intriguing  implementation  language  for  certifiable  systems  code  with 
significant  reductions  in  the  required  certification  effort. 

Another  interesting  potential  is  to  relax  the  pattern  matching  restriction  in  VeriML,  where  proof 
objects  cannot  be  inspected,  in  order  to  develop  procedures  that  extract  knowledge  by  looking  into  the 
structure  of  existing  proofs.  For  example,  one  procedure  could  generalize  the  steps  used  in  a  specific 
proof,  in  order  to  create  a  tactic  that  can  handle  proofs  that  are  similar  in  structure.  Designing  a  tactic 
that  corresponds  to  the  word  “similarly”  as  used  in  informal  pen-and-paper  proofs  is  a  very  motivating 
research  problem  for  future  proof  assistants.  We  believe  that  VeriML  constitutes  a  good  framework  to 
support  experimentation  with  such  ideas,  because  of  its  language-centric  nature,  its  treatment  of  trivial 
steps  in  proofs  and  its  pattern  matching  capabilities. 

Last,  we  believe  that  the  design  of  VeriML  and  especially  our  treatment  of  combining  a  typed  object 
language  and  a  typed  meta  language  could  be  useful  in  the  context  of  normal  functional  programming 
languages.  One  such  example  would  be  to  add  staging  support  in  languages  such  as  OCaml  and  Haskell, 
with  the  ability  to  pattern  match  and  manipulate  the  code  of  later  stages.  In  this  way  we  would  be  able 
to  write  optimization  stages  programmatically,  something  that  would  be  especially  useful  in  the  context 
of  embedded  domain-specific  languages.  Ideas  similar  to  the  extensible  conversion  rule  would  be  useful  in 
this  situation,  in  order  to  provide  extensible  type  checking  for  the  embedded  languages. 
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